Comparing to Artemis

[baconcheese113]

Hey! First off thanks for all your effort in both this lib and graphql_flutter....I'd probably go back to React Native without these. I read you were inspired by Relay and I think that's awesome! Relay is probably my favorite client-side graphql development tool, even more so than ApolloClient.

I switched from using graphql_flutter without static types to Artemis a month ago, and unfortunately I'd say it has just about as many cons as pros from my experience so far. Some of these are probably due to Dart limitations in the difficulty of working with json objects when compared to how easy typescript handles them....but still limitations regardless.

I made an Artemis example project to document my findings and put some of the limitations there. I'm getting ready to make a similar example project with graphql_codegen and just wondering if the roadmap includes some features that Relay had and if the same limitations of Artemis exist in graphql_codegen.

Here and here are an example of how I was using graphql with graphql_flutter.

Here and here are an example of how I used graphql with ApolloClient. This is very similar to how I was using with Relay, except at the time I used the fragmentContainer HOC

With Artemis I'm constantly running into name collisions with sub fields defined in different fragments, and just using nested fragments in general. Also moving Queries/Fragments out of the file they're used in has made it harder to refactor code and prevent over-fetching once the variables are no longer used in that file. Here are some of the issues I had with Artemis comigor/artemis#392 and comigor/artemis#394 I'm at the point now where I'm spending 10 minutes adding new functionality and then 20 minutes wrestling with Artemis to generate types correctly for my nested fragments without name-collision errors, and since I have to alias the sub-fields for them to work I'm sometimes fetching 5x more data for the same query without Artemis because each aliased field is resolved separately.

So my questions:

1. Do you have plans to allow Queries/Fragments to be defined in dart files? Can you elaborate about where the challenge is here and how it might be approached?
2. How do you avoid the field name collision problems that Artemis has?
3. Can you pass nested fragments down the widget hierarchy without issues?
4. Do you have plans to allow a dataId to automagically be added to types that contain it (similar to how __typename is), since it's required for cache normalization?

[budde377]

Thanks for reaching out, let me try and answer your questions:

Do you have plans to allow Queries/Fragments to be defined in dart files? Can you elaborate about where the challenge is here and how it might be approached?

I've considered it, it amounts to analyzing the dart files and come up with a way to link the generated queries to the right methods/widgets. It is doable, but will be different than Relay because of the difference between the TS/Flow type system and Darts typesystem. Not unmanageable, but not started.

How do you avoid the field name collision problems that Artemis has?

By a better implementation of how fragments are mapped to serializers. You can read more here.

Can you pass nested fragments down the widget hierarchy without issues?

I'd certainly hope so! A big part of the motivation for writing this library was that I disagreed with how Artemis handled fragments. If you experience any problems here, please open a issue.

Do you have plans to allow a dataId to automagically be added to types that contain it (similar to how __typename is), since it's required for cache normalization?

Certainly sounds doable. Feel free to open an issue.

[baconcheese113]

Finished the example app and write up https://github.com/baconcheese113/graphql_codegen_example I did attempt to switch the generated directory to an absolute one /lib/__generated__ but was unable, the build finished successfully but didn't build any files

But overall, really enjoyed the experience with graphql_codegen so planning to migrate my main app over to using it next and hoping that it handles my nested fragments better than Artemis. I'll try to keep track of what changes I need to make and see if I can put together a migration guide.

Outside of types not including fields of nested fragments, I didn't come across other features that would make me recommend using Artemis over graphql_codegen

[budde377]

Thanks for documenting your journey! I'm looking forward to seeing the migration guide.

Regarding the absolute paths, I looked at the example package and I noticed that it's using v0.10.0-beta.7. Can you try the following:

• Upgrading to the newly released v0.10.0
• Set the asset path, so if you're placing your graphql files in /graphql your asset path could be: graphql/**.

And try again.

[manuelduarte077]

uff very good talk they had haha, I learned a lot about how graphql_codegen works, I've been using graphql_flutter with artemis for a while but I wanted to try this, it would be good to create more examples, I'm going to create examples using graphql-flutter and graphql_codegen, so that we have more documentation.

[baconcheese113]

The migration was actually very smooth, took a while because there were a lot of places that needed to be refactored, but it was also nice fixing a ton of hacks used to get Artemis working.

Migration guide is here

[budde377]

Great work!

[vasilich6107]

Small comment about Artemis.
The main issue of all is a lack of maintainers and contributors)
We are welcoming all PRs but there is a lot of them coming into pipeline. So current state is “it somehow works”)
There is definitely a room for improvements but the cost of improvements in comparison to profit is pretty high.

I do not have time to make global shifts in Artemis library and I’m ok with how it works now)
I’m trying to fix critical bugs in Artemis. That’s all I have time for :-)

[baconcheese113]

Totally understand, and you're not even the repository owner so I imagine there are some other collaboration challenges! The reason for this discussion was mostly to talk about the current state of graphql type generators for Dart and see which aligned more with the functionality I needed

For new Dart users (myself included) it can be difficult to decide which library to choose for a new project, so I'm hoping this discussion and my example projects with both Artemis and graphql_codegen help users quickly understand the limitations of both and decide which is better suited to their project

@budde377 was an Artemis user and was inspired by it when creating graphql_codegen, so we're very thankful for your efforts (along with the efforts of the other contributors). You might find #142 interesting as well

[oyatrides]

For new Dart users (myself included) it can be difficult to decide which library to choose for a new project, so I'm hoping this discussion and my example projects with both Artemis and graphql_codegen help users quickly understand the limitations of both and decide which is better suited to their project

It is exactly my case, and this discussion tremendously helped me (and soothed my mind) to validate my choice.
Thank you a lot for your work.