I am working on a project with GraphQL and therefore I have reviewed some popular client packages. The top 3 packages I can search are artemis, ferry and graphql_flutter. My usual state management approach is bloc and provider. This makes me try to avoid using the provided flutter widget directly updates the children widgets. The following review is based on my POC bloc project playing with these three packages.
Basic information I have found (22/06/2022):
| artemis | ferry | graphql_flutter | |
|---|---|---|---|
| publisher | borges.dev | gql-dart.dev | zino.company |
| Enough documentation to install | Yes | Yes | Yes |
| Enough example or documentation to implement basic request | Yes | Yes | Yes |
| Own community chat group | Yes | Yes | Yes |
| Scheme class code generation | built in | built in | No built in, but author has suggested a package to do this (graphql_codegen) |
| Current maintain status | Actively updating | Looking for maintainers | Actively updating |
When I use these three packages with a simple GraphQL project for test, I find that they somehow similar to the Apollo client. It is not hard for me to use them for simple query or mutation. Although all of the packages have multiple dependance, the installation of graphql_flutter is the easiest one because there is no built in code generation.
Is code generation really necessary for the GraphQL in flutter? It depends on the scale of the project or the size of scheme you use. If it is just a small project with a few request, I do not see any advantage on the code generation as it does not take much time for me to write my own. If the scale of the scheme used is large, a small enum changed affects a large area. Code generation in this case is really helpful.
And a fun fact, the core gql package these three packages depending is from the gql-dart.dev and all of them are stream based which I can easily listen the snapshot or subscribe from the client. Using bloc or provider handling the state management, the flutter widget they provided does not interest me a lot. Most of the time I am listening to the result in the bloc or provider classes. What concerns me more are the maintain status and the flexibility of overriding generated classes. artemis and graphql_flutter + graphql_codegen are more suitable for me. Personally, I prefer more on the graphql_flutter + graphql_codegen. graphql_flutter is simple and straight forward on installation and requesting and graphql_codegen is flexible on the graphql fragment handling. The author of the graphql_codegen have an article talking about this. You may take a look at it to see if the use case suit you.
After all, it is the package suit your case, not making your case suit the package. You can even use a dio to make a graphql request. If you have your stories on using any approach with GraphQL, both good or bad one, please feel free to share with us on the comment. This will help us a lot to choose the approach and avoid the same mistakes.
Support me if you like the content🍖
Connect🍻
Top comments (0)