This will take your GraphQL queries and mutations, check them against the schema and anything else that cause your query to fail at runtime, and then generate Elm code you can use!
If it runs into an issue, you get a nice error message.
We write a ton of GraphQL at Vendr (and at Blissfully before we were acquired by Vendr), and this tool has been in production for over a year. It’s been a huge productivity booster for us and we can’t wait to see the Elm community reap the benefits as well.
This also uses —and was one of the prime motivators for— Elm Codegen.
This also represents Vendr’s first official foray into contributing to open source for Elm.
Nice to have a billion dollar company at your back.
Move fast, break nothing.
Writing GraphQL directly means you can move very fast, you can use whatever editor plugins you prefer, and have access to autocomplete and all kinds of other goodies.
But there’s no compromise here with typesafety.
In fact we found that there are other strong benefits to having .graphql queries live in your code — it provides an easy on-ramp for backend programmers who aren’t as familiar with Elm to just jump in! And you have an easy way to audit exactly what data is being requested, which is huge for right-sizing data requests.
A backend programmer’s most common interaction with the frontend is usually something to do with the data layer, so if their first interaction with Elm is requiring them to read and write decoders, it’s a little rough . Fortunately this gets around that because you get decoders for free.
Right now it doesn’t, but that’s mostly because we haven’t started using subscriptions at Vendr. I don’t have explicit plans to add them, but they’re probably not that hard to add!
So if someone wanted subscriptions and was using elm-gql, I’d probably add them
I’m currently using ports to query and subscribe to a Hasura GraphQL API for konsens.it. I will give elm-gql a spin for the queries and will probably be in touch for the subscriptions once this is working well.
I generally hang out on the Incremental Elm Discord server if you want to join. There’s an elm-gql channel where the current discussions about development are happening.
I like elm and graphql and have mostly used @dillonkearns awesome elm-graphql package. How does this compare to that? Is it meant to compliment it or replace it?
vendrinv/elm-gql is an alternative to Dillon’s library!
We’ve used Dillon’s lib a lot at Vendr/Blissfully, though we’re in the middle of switching over to vendrinc/elm-gql. For the moment we use both.
At a very high level the trade off is something like
dillonkearns/elm-graphql lib allows more customization on finegrained mapping of the retrieved GQL data into your Elm types.
Our library generates the types for you, while giving you a few ways to affect the generated code. The main benefit is how fast the GQL can be modified, read, and maintained.
Both approaches are fully typesafe.
One of the main aspects that will come up in evaluating both approaches is how you organize your UI state code. I talk about that a bit here in regards to how to approach things with vendrinc/elm-gql.
There is an Elm Radio episode that will come out at some point where we talk about the tradeoffs.
This also represents Vendr’s first official foray into contributing to open source for Elm.
Move fast, break nothing.
. Fortunately this gets around that because you get decoders for free.
