-
-
Notifications
You must be signed in to change notification settings - Fork 147
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
SDKs for various environments #54
Comments
Dart Flutter would be cool. Is has full GRPC and Protobufs support too. The other options is to compile the golang using gomobile and embed it inside flutter: also a high level discussion about it. Let me know if you want some help. Yorkie looks really good ! Also i noticed your using the envoy Proxy. |
@gedw99 I didn't know about Dart Flutter, but thanks for letting me know. And thank you for your interest in Yorkie. Providing a Flutter SDK seems like a good idea. But these days, I am working on the server, so it is difficult to me to directly develop the Flutter SDK for now. When someone is working on the Flutter SDK, I think we can talk and I can help the one to implement Yorkie's algorithm. |
I can do the flutter layer. Your architecture is very similar to our project, since you use envoy and grpc-web etc. The team is in Telegram btw: I am really interested in the CRDT Server and offline editing, and think i can help with it since we all program in golang and flutter |
I managed to get the Golang girlie client running inside flutter web and native ( mobiles and desktop ). I had to do some very bad hacks though. I just wanted to see how it behaved. I am trying out a client side dB called genii. |
Sorry I pressed return too early. The protobuf pub sub or looks really nice btw. For the ja and react clients do you have a client side dB ? |
So for Dart then everything in the following will need to be ported to Dart in order to use this in flutter ? |
@joe-getcouragenow That's right. Under the I think it would be helpful to figure out the scope of developing SDK based on the JS SDK. |
Not sure what your mean by the above. |
I mean, it would be helpful to develop new SDK in other environments or languages with reference to the already developed JS SDK. |
got it. How about we WASM the golang code above ? from your JS layer its easy to use. Its a good candidate because its simple code, and you just need to inject the data you get over the wire into it and get the result out. Very good worker architecture. If you dont like this we can also do it the traditional way... |
@gedw99 There is no local DB on the JS SDK yet. Later, when we introduce local DB, we can store each property of the Document. I think it will be easy because we use Protobuf. |
@joe-getcouragenow I don't know about WASM yet, but I think it's a good idea if it can be used in multiple environments. |
So I think in order to support any client envoy proxy will be needed. You can easily run it in the docker compose. This allows grpc to work with web ( grpc-web ) and native ( grpc ). It will also make the system scale horizontally because envoy proxy runs as s sidecar to each server service. You can update the envoy config for all instances using the envoy grpc API. This will mean that when you codegen from the grpc protobufs the generated code for all clients ( any language or web or native ) will just work. https://github.com/envoyproxy/envoy/blob/master/examples/front-proxy/docker-compose.yaml Also Auth and authz can be done with envoy too The rest or your Architecture remain mostly untouched . In fact alot of the code on the clients and servers will not be needed due to the code generation. |
@gedw99 Thank you for the explanation. I wonder if you are going to work on what you said. |
Awesome.... I think the first thing is to move the docker compose that has envoy in it into the yorkie repo. @hackerwins i think that pretty easy to do on your side first ? Then i think automatic TLS is needed, so that its very easy to boot an Envoy with LTS.
Also the envoy config should be setup to run as an edge proxy, as its not being used as a Services mesh in the Yorkie context right ?
Once the Yorkie repo has this then its easy to add autocert integration for Lets Encyprt.
I am working on that now. then i think the WASM of the types using tinygo is next. These types: Because those types are so simple and have no reflection, tinygo can do it. I am working on that now. Finally... At this point we can support all clients types and all languages.
|
All: let me know if you want to change anything Or if you like this approach |
Sounds good to me 👍 Background on auto TLS : We need a provider. Probably autocert like what the golang team uses ? |
@hackerwins |
@hackerwins you might be interested in the GIO golang gui. its 100% golang for Web, Desktop and Mobile. The underlying design is like Flutter in that its a canvas that the GPU ( webgl canvas in webs case ) renders to. The advantage with yorkie is of course that the backend and frontend gui is all in golang, so it can make things easier. Especially from an SDK point of view because you can share code on both side. If you want more info let me know .. https://github.com/planetdecred/godcr is a good example of a big app btw |
We created |
Description:
We provide Go Client and JS SDK. It would be good to implement the SDK in the following order.
Why:
Users can use Yorkie in a variety of environments.
The text was updated successfully, but these errors were encountered: