feat: Build grpc API with swift-bridge and package with Swift #50
Conversation
…d size, trying to add tls now
|
Copying all our protos into this package seems less than ideal. Maybe a project for me next week is to avoid the need for that |
Oh yeah I should make them a submodule now actually. Let me fix that. Edit: actually I have |
|
I'm hoping to get around the nightmare that is our proto repo build process by using Buf Schema Registry. Just pushed up the first package. Submodule is fine for now, but I'm happy to take on buf-ifying this thing on Monday as a test before I buf-ify the mobile SDKs. |
|
@neekolas this commit addresses the base64 issue in a very targeted and brittle way. As long as we only serialize the MessageApi protos to JSON this should be fine, but gotta keep an eye on this for sure. |
For a prototype, that all seems fine. I suspect we're going to want to pass these back and forth as structs to optimize perf at some point. |
* Initial commit * Include lib * Add features * Correct import * Add feature * Add pbjson * Almost passing * Add build.rs * Add .gitignore * Rename folder * Remove generated code * Gitignore generated * Automatically install required dependency
|
Gonna add one quick fix to |
| topic: String, | ||
| paging_info: Option<v1::PagingInfo>, | ||
| ) -> Result<v1::QueryResponse, tonic::Status> { | ||
| let mut client = v1::message_api_client::MessageApiClient::connect(host) |
There was a problem hiding this comment.
At some point we are going to want to optimize this to re-use a long-lived GRPC connection, given how nice and performant it is that GRPC can multiplex a single HTTP/2 connection.
But that's a problem for another day.
|
FYI: I removed |
Overview
Top-level issue link
This PR goes hand-in-hand with an update to our Swift package repo to hide all of this nonsense behind a single API defined in
ApiService.swiftin that repo.Why is this PR so big?
Things to ignore: 1) generated Rust proto code 2) generated Rust-Swift binding code 3) I also deleted
corecryptofrom the crate cause we didn't need itWhat changed in the Rust<>Swift flow?
xmtp-ios should just be consuming a run-of-the-mill Swift package with a super simple Swift-only API.
How we did this was:
Cheaders and Swift files from our codeCheaders into ourincludedirectory to get bundled into the XMTPRustSwift.xcframeworkxmtp-rust-swiftafter adding an "import XMTPRustSwift" line to each filexmtp-rust-swift(our Swift package), we use the XMTPRustSwift.xcframework, wrap it with ApiService and deliver a nice clean Swift package interfaceRight now the shim strategy is to convert protos to JSON and throw them across the Rust<>Swift boundary. We can optimize this as necessary but number one priority is to get it working.
Next Steps
Need to implement "subscribe" and make sure our Rust gRPC can target TLS.
Test Plan
Bring up a local xmtp-go-node with gRPC port mapped to 15555 (or change port in the test) and run unit tests.