Disclaimer: I’m an author of http://absinthe-graphql.org/

We’ve had great success with GraphQL. To clarify questions about what differences exist between Absinthe and GraphQL-Elixir I’ll quote a recent mailing list post:

As you might expect, this has come up. Besides the “name” issue, there’s also the fact that the subject of GraphQL isn’t a simple topic, and it’s hard for new users to evaluate solutions adequately. I mentioned as much on Twitter during ElixirConf EU: https://twitter.com/wbruce/status/730778840310616064

From a technical perspective – as far as we can see – there are no advantages that graphql-elixir currently has over Absinthe. Absinthe is more complete, faster, checks for more errors (& at compilation time), has broader production usage, more discussion, better spec coverage, superior documentation, etc. Our needs to use it in production have really pushed us to develop features, hammer out bugs, and develop other integrations like Absinthe.Relay as more than just an item on a checklist.

The graphql-elixir team and our own are on amicable terms, and we discuss things regularly – but as the internals, approaches, and scopes of the projects are so different, at the current time, there’s not a plan to merge (from our perspective, there’s nothing from graphql-elixir that would make sense to, besides possibly some spec test cases).

Absinthe is by no means perfect. There is code in the main Absinthe project itself that could be improved, and there is a long list of features on our roadmap we would like to implement (projection, query complexity analysis, deferred queries, etc). We would definitely appreciate help there and in general, but it seems clear that the graphql-elixir team is going to continue to work on their separate implementation – a choice that I think is completely reasonable for them.

The question, really, is what the community chooses – and whether a “merged” version (even if just team merging) is the way forward. We have no plans to retire Absinthe’s source – it’s a critical production dependency for us – and, as I said, it doesn’t appear the graphl-elixir team has plans to close up shop either. In the meantime all that Ben and I can do is continue to improve Absinthe every day while we support our users and improve our own production infrastructure.

Whether the community makes an implicit choice or a specific project makes an explicit endorsement isn’t something we can control, but we’re always open to discussing the comparative benefits of our implementation, and collaborating on any way we can to better support GraphQL for Elixir developers.

If anyone’s interested, you can find Absinthe at http://absinthe-graphql.org, and our Slack chat via http://absinthe-graphql.org/community

Cheers,
Bruce (& Ben)

With respect to GraphQL itself, we’ve found it to be a great experience. From a developer perspective, strong typing on the inputs and outputs of the API removes tons of boilerplate you usually have around checking parameters, parsing stuff like dates / times / geolocation coordinates, and walking nested maps with string keys.

It’s also been great from the perspective of coordinating front end and backend teams. You simply agree on the kind of documents you want to work with. Then you just write some tests with those documents, and when they pass, you’re good to go!

If I want to have some alternative to REST I would check what big giants are using like Neflix Falcor or Facebook GraphQL.
Resources:

• Awsome GraphQL (Some elixir implementations)
• Awesome Falcor

Thanks. Jean-Jacques Dubray has some things to say about GraphQL in this overall interesting article btw: Why I No Longer Use MVC Frameworks - InfoQ