-
Notifications
You must be signed in to change notification settings - Fork 19
feat: port Wire Android services & use cases - WPB-16148 #2920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
…e:dataPath:metadata:uploadStatus:)` compile error
Perhaps we can delete these but I will comment them for the time being
It is not clear to me what this TODO means.
# Conflicts: # wire-ios-data-model/Resources/zmessaging.xcdatamodeld/zmessaging2.125.0.xcdatamodel/contents # wire-ios-data-model/WireDataModel.xcodeproj/project.pbxproj
This commit doesn't contain any new/updated entities - just the new model
Test Results2 788 tests 2 783 ✅ 4m 57s ⏱️ For more details on these failures, see this check. Results for commit 11f060d. ♻️ This comment has been updated with latest results. |
Datadog ReportBranch report: ❌ 4 Failed (0 Known Flaky), 2783 Passed, 1 Skipped, 4m 36.22s Total Time ❌ Failed Tests (4)
|
import XCTest | ||
|
||
@testable @preconcurrency import WireCellsImplementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted these tests as WireCellsService
no longer exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some comments mostly about project structure since this PR is porting code from Android maybe there will be adjustments in future PRs to align to our codebase.
case failedToCreateWriteStream | ||
} | ||
|
||
public protocol WireCellsCellsRepository: Actor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: shouldn't this live in WireDomain with the other repositories ? Also the naming is strange, could it be simplified to WireCellsRepository ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand our goal is to move more of these kinds of things to feature modules. I don't think there is any benefit of having this in a shared module when it will only be used by wire cells
Regarding naming, I agree it is strange but I essentially it is saying that it is the CellsRepository
and belonging to the WireCells
feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding naming, I took another look at this. In general I think Node
is the better term than Cell
as this is how things are referred to in the pydio API. Therefore I've renamed all the ...CellsCell... types. For example,
WireCellsCellsRepositoryis now
WireCellsNodesRepository`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's as feature module, do we need prefix WireCells
at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmitrysimkin It's a good point. Perhaps everything that is not public
can be without the WireCells
. I will leave as is for now and rename as I work more on the feature.
case missingData(String) | ||
} | ||
|
||
package protocol WireCellsCellsAPI: Sendable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: this looks like an API interface, should this be moved to WireAPI ? Also the DTO returned objects is something I haven't seen in codebase yet.
Since this code is ported from Android, I'm note sure if it's just a first PR and things will change to adapt to our codebase in next PRs or is it some new code structure we adopt.
Also should it be renamed to WireCellsAPI ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. The way WireCells interacts with backend is different then the other parts of our app - in fact it doesn't talk to wires backend at all. Instead it uses:
- AWS SDK
- Cells SDK which is network client generated from the swagger specs.
Therefore I don't think WireAPI
is the right place for it. Regarding DTO, Thomas basically took everything as is including naming strategies from Android. This was done for speed and the idea that if we don't understand something we can ask the Android developers. Personally I'm in favor of merging first and then adopting as needed and unifying patterns with our code base.
Regarding naming I will ask in the developer channel for opinions.
import WireCellsAPI | ||
import WireDataModel | ||
|
||
extension WireCellsMessageAttachmentsDraftsLocalStore: WireCellsMessageAttachmentDraftDAO { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: to be aligned with other local store stores protocol naming I guess it should be WireCellsMessageAttachmentDraftLocalStoreProtocol
instead of WireCellsMessageAttachmentDraftDAO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you. But I'm in favor of merging soon and aligning terms in follow up PRs as we use these objects in practice and understanding better the DAO term. We are already using the concept of a DAO - see UpdateEventMigratorDAO
but here that is the concrete implementation and the protocol is UpdateEventMigratorDAOProtocol
.
So in summary, I'm in favor of aligning better with our exist codebase / future direction but would like to merge this PR quickly while spending some more time to think about these terms and probably discussing further in the architecture forum.
} | ||
|
||
// sourcery: AutoMockable | ||
public protocol WireCellsMessageAttachmentDraftRepository { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: should this be moved to WireDomain as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the same answer here as your point about WireCellsCellsRepository
|
||
/// Returns a pre-signed URL for the given S3 object key. | ||
func getPreSignedUrl(objectKey: String) async throws -> String | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like another API interface, should it be moved to WireAPI (and probably renamed as well) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned about, I don't think so because we don't actually talk to the WireAPI. See comment above. If that changes we should perhaps move this to WireAPI but otherwise it is very specific to this package so I think it is best to keep it here.
public var id: String { | ||
"\(uuid.uuidString)@\(domain)" | ||
} | ||
|
||
public var pydioQualifiedID: String { | ||
"\(uuid.uuidString)@\(domain)" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: sanity check, shouldpydioQualifiedID
be same as id
? if so you can use reuse id
for pydioQualifiedID
// /!\ Will silently filter out nil values that could not be mapped to DTOs | ||
nodes: nodes?.compactMap { $0.toDTO() } ?? [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: is this smth that needs to be addressed now or later?
import CellsSDK | ||
package import Foundation | ||
|
||
package struct WireCellsNodeDTO: Equatable, Hashable, Sendable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: why do we need DTO? Usually DTOs is not pass between layers, is it case here?
} | ||
|
||
// sourcery: AutoMockable | ||
public protocol WireCellsConversationDAO { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Why is it DAO? Looks like a use case?
func addAttachment( | ||
uuid: UUID, | ||
versionID: String, | ||
conversationID: WireCellsConversationID, | ||
mimeType: String, | ||
fileName: String, | ||
fileSize: UInt64, | ||
dataPath: String, | ||
nodePath: String, | ||
uploadStatus: WireCellsAttachmentUploadStatus, | ||
assetWidth: UInt64?, | ||
assetHeight: UInt64?, | ||
assetDuration: UInt64? | ||
) async throws(WireCellsMessageAttachmentDraftDAOError) -> WireCellsMessageAttachmentDraft |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: too many params, would be nice introduce input model
case failedToCreateWriteStream | ||
} | ||
|
||
public protocol WireCellsNodesRepository: Actor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: looks like too many methods in one repo, better split them into smaller ones, wdyt @samwyndham ?
import Foundation | ||
import WireCellsAPI | ||
|
||
final class WireCellConversationDataSource: WireCellsNodeConversationRepository { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: naming is not consistent, e.g. we have Implementation
for Client
WireCellsAWSClientImplementation: WireCellsAWSClient
but for repository protocol implementation we have DataSource
. can we make it consistent?
private enum Constants { | ||
static let bucket = "io" | ||
static let multipartChunkSize = 10 * 1024 * 1024 | ||
static let maxRegularUploadSize = 100 * 1024 * 1024 | ||
static let preSignedUrlExpiryInHours = 24 | ||
static let readAsyncChunkSize = 5 * 1024 * 1024 | ||
static let region = "us-east-1" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise : for adding constants
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good overall, approving to unblock future tasks on WireCells, my assumption though is that things will be adjusted a little architecture wise as the feature moves forward
Issue
Ports and integrates the Android WireCells services & use cases interfaces & implementations to the iOS app.
Remaining
Tests for this PR will be done in a follow up ticket: https://wearezeta.atlassian.net/browse/WPB-17490
Testing
None of this code is used yet so cannot be manually tested
Checklist
[WPB-XXX]
.