[FEATURE] Dart/Flutter Support?
Why do we need this improvement?
Dart/Flutter now has a HUGE following and is 25% of all apps in the app stores. It would be highly beneficial if we could automatically generate clients and models for Dart using the Generator.
How will this change help?
By being able to generate Dart clients from AsyncApi it will eliminate a ton of boilerplate code that often breaks right now in Dart and we can couple to our servers
Screenshots
No response
How could it be implemented/designed?
Just a generator that generates all of the models (the page I found for dart thinks it's go... https://modelina.org/examples?selectedExample=generate-dart-models) and should generate clients automatically as well.
๐ง Breaking changes
No
๐ Have you checked for similar open issues?
- [x] I checked and didn't find a similar issue
๐ข Have you read the Contributing Guidelines?
- [x] I have read the Contributing Guidelines
Are you willing to work on this issue?
No, someone else can work on it.
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
@JohnGalt1717 hey and thanks for the suggestion. Some followups:
- you are referring to some specific protocol, I guess for mobile it would be websocket?
- if you are not interested in contributing, can you at least share examples of such client code?
- would you be able to at least join reviews and do manual tests of the clients?
- best if you can also share some example AsyncAPI documents that would be used for such client - can be anonymized
btw, for models, you do not need generator. We can of course include models generation in such client template, but for models only you can already use https://github.com/asyncapi/cli and command like asyncapi generate models dart ./asyncapi.yml
Yes, I was thinking 2 different types of clients:
https://pub.dev/packages/web_socket https://pub.dev/packages/signalr_netcore
And then model generation.
The idea here being that raw web_sockets if that's what you're using and then signalR for those using it.
I see https://pub.dev/packages/web_socket_channel is more popular
although future goal of code gen here is to be super modular and support clients for one protocol and one language with different libraries/frameworks
Not picky about which client, really as long as it's maintained. Last time I looked that one was separated into 3 modules for web, ios and android and no others. Looks like it's unified now so cool.
@JohnGalt1717 @derberg
I'd suggest we start with basic WebSocket client generation targeting web_socket_channel, include model generation integration with the AsyncAPI CLI, focus on a modular design that could later support different protocols/frameworks, and add proper error handling and reconnection logic out of the box.
That works for me. SignalR just delimits its messages across the wire with a special character so there isn't a large lift.
Would love to see this implemented! For now though, I think I will model my API using Modelina and manually handle interactions with any websocket clients.
What do you think is the effort to implement Websocket client generation using web_socket_channel for someone familiar with Flutter/Dart but not with asyncapi/generator? If it's not actively being worked on, maybe I could give it a shot
@Parthib modelina will only give you classes, nothing else.
I suggest first draft an expected client, basic one, how it would look like and how it would be used. Then templating is much easier
@derberg I tried to draft a client-postman also example usage of it. Maybe you can look it and provide some feedback. thanks : ) https://docs.google.com/document/d/1zr1-F0zK8rsa4bcX66oQSC-QaxvRo4b8CVy6YBlJwMs/edit?usp=sharing
@Adi-204 why google doc? to receive comments? Just open a PR, you know where technically we keep examples, and where we keep test-generated clients - just reflect that (of course I know we normally do not commit the generated clients - it would be only for review). And create it as Draft PR
will be much easier to engage people in review.
the most important comment: you do it exactly the way it should be done, not only show expected client, but also provide an example code so we can see how it would be used ๐
@derberg ok I will working on it and create a draft PR. I thought maybe first show you an overview of how client and example code will look like and then go for PR. But ok I think draft PR is amazing ๐.
@JohnGalt1717 @Parthib @shwetd19 please folks look into the PR. You can ignore the template code. Just look at the generated files located at packages/templates/clients/websocket/dart/test/temp/snapshotTestResult/ and share your opinion
Hey @derberg , I took a peek at the generated files in packages/templates/clients/websocket/dart/test/temp/snapshotTestResult/. They look good for a Dart WebSocket client! The methods seem to line up with what Iโd expect from an my spec. One thing, thoโmight wanna add some reconnection stuff in case the socket drops. Whatโs your take? Lemme know if you wanna bounce ideas!
Looks good. Is there any framework for generating the objects on these? (serialization/deserialization) or exposing the models like OpenAPI does?
yes, there is, at AsyncAPI there is one community project called Modelina and it does pretty nice job and we have a component that uses modelina for types generation. I see there is support for Dart -> https://github.com/asyncapi/modelina
just share should these be generated, in reference to existing example? any patterns in Dart to follow? Also, at the moment we have pretty basic examples of Postman and Hoppscotch APIs that do not have any specific schemas for messages - as dumy as any so hard to show it in action.
I'll start working on https://github.com/asyncapi/generator/issues/1418 probably this week, but then you know, Easter break
Awesome stuff. Thanks!
It looks good to me. I don't work with websockets directly and use signalR so trying to figure out how I'd adapt it natively to support SignalR.
@derberg what more changes are we thinking of for this issue? Can I convert the draft PR to normal? Or wait for more inputs?
@Adi-204 go ahead and convert
I don't work with websockets directly and use signalR so trying to figure out how I'd adapt it natively to support SignalR.
@JohnGalt1717 sorry, but can you explain more? How is signalR (that I believe is .NET-related) relates to Dart client?
Dart (Flutter) is heavily used with C# backends. Flutter is now the No. 1 most popular tooling for apps in the app stores and is increasingly being used for Web. Because Dart and C# are very similar and C# doesn't have a serious alternative to Flutter (and Dart doesn't have a serious backend alternative to C#), you see this matchup a lot.
On C#, it will be producing SignalR compatible websocket implementations. Flutter needs to be able to use the C# signalR hubs hopefully with asyncapi, to properly handle the SignalR comms on the Dart/Flutter side and strongly type everything all of the way through and support streams as well just like you can do with OpenAPI in the rest world.
Hence why I mentioned both the websocket regular and then signalR client for this in the 3rd comment above.
ok, so C# backed using SignalR exposes an WebSocket API that Flutter through Dart is consuming - thus you need Dart client for the app.
SignalR generation will be useful too though
The nuance is that SignalR generates websockets with a specific framing and termination, so just using websockets without the understanding of the framing on the dart side won't work.
you mean connection termination? heartbeats? the ping pong? how to know connection is open and how to make sure it is not terminated?
and what exactly you mean on framing?
SignalR terminates every message with specific characters as an example. I can't remember exactly what it does, but it isn't just pure WebSocket even in Websocket connection mode. (and it can do long polling etc too, hence the library I recommended to use for signalR)
The initial version of dart websocket client is merged ๐. In packages\templates\clients\websocket\dart you can find README.md in which steps are give how to play with the current simple implementation. So try it and provide suggestions ๐ !
now we can add models generation as we see it working in python template.
so next step is to use Models component, and in dart template dir put it into subfolder so models in generated output end up in subfolder and not as flat structure. The only question is what is the name of the subfolder we should use. In dart what people usually call folder with models, is it models? classes? or something else
@derberg generally "models".
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience :heart: