Introducing Graphqelm, a Tool for Type-Safe GraphQL Queries

Show and Tell
5

Hey @noahzgordon, thanks for the question! Perhaps I should make it more clear what differentiates my package from the other ones out there in my README as I’m sure this is the first question people will ask when they see this package.

I have looked at all the different offerings and spoken to some of the other package authors. What it comes down to is that there are 3 different approaches out there right now for Elm GraphQL packages:

1) No code-gen, DSL to build up a Decoder and Query with the same code

With these packages, there is no help to guarantee that your queries will be valid according to the schema.

  • jamesmacaulay/elm-graphql - this is the most popular GraphQL package right now
  • pro100filipp/elm-graphql - this is just a fork of jamesmacalulay’s package with some minor changes
  • ghivert/elm-graphql - this package is actually a special case of the no-code-gen approach, you write your decoders separately and it only helps you generate GraphQL requests.
  • Xerpa/elm-graphql - a fork of ghivert/elm-graphql with remote-data support.
  • chrisalmeida/graphqelm - similar to ghivert/elm-graphql's approach, this doesn’t deal with the decoders, it only builds requests.

2) Schema & Query Document => Generate type-safe code for that specific Query Document

With these packages, you give it a specific request and it will generate Elm code for only that request.

  • jahewson/elm-graphql-module - No Elm 0.18 support
  • base-dev/elm-graphql-module - Broken Elm 0.18 code generation This is a fork of jahewson/elm-graphql-module. It still depends on the original NPM module for codegen, so it is not in a functioning state.
  • M1chaelTran/elm-graphql - Labeled as a work in progress The readme says that it’s still being worked on at a bi-monthly hackathon.

3) Schema => Generate type-safe code for entire schema

  • dillonkearns/graphqelm - this is the only package out there that takes this approach. I built this package because I wanted to have the type-safety and simplicity that I love about my favorite elm packages!

Differing Goals

Here’s why I chose not to merge with existing packages.

jamesmacalulay/elm-graphql is the most popular GraphQL package right now (it’s under approach #1). James considered adding a whole-schema code generation feature like dillonkearns/graphqelm, but decided to abandon the idea and stick to approach #1, here’s the thread. I think these are different enough goals and approaches to warrant a different package, and I needed a whole new set of code to support this so it didn’t make sense to try to build off of this package either.

jahewson/elm-graphql-module had a lot of momentum behind it before Elm 0.18 (which it doesn’t yet support). I made a point about how, in my opinion, there’s no need for packages with approach #2 anymore when there is a solid package for approach #3, here’s that discussion.

Thanks again for the helpful question!

8 Likes