[ANN] Absinthe v1.0: GraphQL for Elixir

[Bruce Williams]

Hello everyone!

TL;DR: http://absinthe-graphql.org

This is an announcement that’s been a long time in coming. Since ElixirConf 2015 (October), Ben Wilson and I have been intrigued at the possibility of building GraphQL APIs on top of Elixir & Phoenix. Discussions with Chris McCord and others hinted at some very interesting possibilities down the road, and GraphQL addressed some API challenges we wanted to tackle in our production infrastructure.

If you’re completely unfamiliar with GraphQL, here’s a good introductory article from Facebook: https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html

Fast forward a few months [and a lot of work] later, and we’re “officially” releasing v1.0 of Absinthe, our GraphQL implementation for Elixir. We’ve been running Absinthe in production -- in various, incrementally better forms and we’ve been extremely pleased by the experience. We think you will be too, and we invite you to take a look at it, play with it, and get involved.

We’ve put together a website with some background information on GraphQL, a tutorial showing how to build a GraphQL API with Absinthe & Phoenix, and various topical guides: http://absinthe-graphql.org. We’ll continue to improve the documentation (both on the website and our hexdocs) as Absinthe usage grows.

Absinthe consists of a few projects, all housed in the https://github.com/absinthe-graphql organization:

- absinthe: Core functionality

- absinthe_plug: Plug/Phoenix integration

- absinthe_example: Code for the tutorial

Relay and Ecto-specific integrations are currently underway, as well as a host of other features; see http://absinthe-graphql.org/roadmap.

If you’re interested in the list of GraphQL features (and Elixir niceties) that Absinthe supports, check out the README: https://github.com/absinthe-graphql/absinthe

Thanks!

Bruce Williams & Ben Wilson

[Tobias Pfeiffer]

Wow, thank you for your work! Looks really great, excited to play with it.

Tobi

> - *absinthe*: Core functionality
> - *absinthe_plug*: Plug/Phoenix integration
> - *absinthe_example*: Code for the tutorial

>
> Relay and Ecto-specific integrations are currently underway, as well
> as a host of other features; see http://absinthe-graphql.org/roadmap.
>
> If you’re interested in the list of GraphQL features (and Elixir
> niceties) that Absinthe supports, check out the README:
> https://github.com/absinthe-graphql/absinthe
>
> Thanks!
>
> Bruce Williams & Ben Wilson

> --
> You received this message because you are subscribed to the Google
> Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to elixir-lang-ta...@googlegroups.com
> <mailto:elixir-lang-ta...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-talk/CACZxBvSFvN5TRDo0RLkui4tcz%2BBBRd7%3DursOdT8dh%3DojPA9-tQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-talk/CACZxBvSFvN5TRDo0RLkui4tcz%2BBBRd7%3DursOdT8dh%3DojPA9-tQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Cristian Garcia]

Made my day! This is fantastic. Cant wait to play with this.

On Wed, Mar 2, 2016 at 10:13 AM Cristian Garcia <cris...@aristadev.com> wrote:

Made my day! This is fantastic. Cant wait to play with this.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/56D6AF15.7060803%40gmail.com.

[Greg Vaughn]

Exciting stuff! Thanks Bruce and Ben.

-Greg

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CACZxBvSFvN5TRDo0RLkui4tcz%2BBBRd7%3DursOdT8dh%3DojPA9-tQ%40mail.gmail.com.

[Louis Pilfold]

Hey

This is really very cool! Thanks for all your hard work :)

Cheers,
Louis

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/12CBD340-FAC8-485B-B4F0-F8DF41A5E925%40gmail.com.

[Stephen Moloney]

Sounds good. Github star for this.

[Cristian Garcia]

How does Absinthe interact with Ecto?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAM-pwt4uaVqtuZ39tcVMci5RBYvLtSLGPEvbZhywQfGihDQY2Q%40mail.gmail.com.

[Ben Wilson]

In your schema you specify resolution functions to queries and mutations. Those functions receive any arguments passed to that query or mutation, and can call out to Ecto as desired.

The tutorial covers these cases, and we put up a new guide today with more info on how to handle Ecto associations properly.

[Phani Mahesh]

I have stumbled upon this today from another source. Thanks for the good work! The detailed documentation and guides are impressive.

I also liked the resolution backed by protocols, but noticed that it may not be the most efficient. I was reading on Haxl and related work all morning, so I was thinking of possibilities to optimise queries by batching them as much as possible. My ideas are way too vague to put into sensible words at the moment, but I will contact you in case I make any progress.

Have you thought about batching queries automatically? It should be possible in theory, given database schema and a graphql query, an effecient query can be constructed to fetch all the data, possibly in a single query. Infact there is an experimental graphql plugin for postgresql that does something very similar. It defines functions that take a graphql string and return a good sql statement to get the data in the proper form in a single query, and to execute this generated query.

This would create potentially a strong coupling to the database being used, but probably ecto queries instead of raw sql can be built from graphql so that the coupling is minimized.

[José Valim]

> I also liked the resolution backed by protocols, but noticed that it may not be the most efficient.

FWIW, from Elixir v1.2 it is most likely this is not a concern. On all environments, the extra cost of a protocol dispatch is pattern matching on the type plus one remote call. I would imagine it can be an issue only inside really tight loops.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/a427de1c-6904-48cd-b3d1-1cc9ed1222b4%40googlegroups.com.

[Phani Mahesh]

I should have made myself clearer. I was not referring to protocol dispatch, I was referring to its side effect of generating multiple queries to the database where potentially one can do, given the way the examples demonstrate.

You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-talk/iKcDcNwtHJY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAGnRm4LsZgCGM-bThzmTymadrAZ%2B3MUoQgAFK8omEJCfjpLvEg%40mail.gmail.com.

[Ben Wilson]

We address this in our Guide on Ecto: http://absinthe-graphql.org/guides/ecto-best-practices/

Basically, preload what you need. Additionally (something I'll add to the guide) the second argument to each resolution includes a `:source` key which is the resolved parent item. You can look at that and see if you need to load additional data if preloading intelligently isn't an option.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAO-GxGMhXgzusnU%2BNyGg_RE8ijF%3DPff5zJ7OY9RyVpEuTSpK_Q%40mail.gmail.com.

[Phani Mahesh]

Great!

The last paragraph addresses most of my concerns.
The few that remain are not solved in elixir yet, and are not specific to GraphQL.

For instance, I was toying with the idea of statically analysing the entire codebase to find all possible queries, and optimising them at compile time to compress them to a single sql query wherever possible. This will be nontrivial and a possibly expensive computation, but since we do it once at compile time and reap benefits on every query, it is very tempting. Preloads for instance do not need two queries if table expressions are used, and this particular case may be easier to solve for than the general case.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAM6of9yNdAC%2BCzv3m2E%2B0%2BNt7DZzRzjY8KCR_wrOvS1iZbc4tg%40mail.gmail.com.

[Bruce Williams]

One thing we're very interested in (along that path, generally) is the query complexity analysis that Sangria (Scala's implementation) provides: http://sangria-graphql.org/learn/#query-complexity-analysis -- of course this is different than actually trying to optimize any underlying queries.

This and query depth limiting are things we plan on addressing as soon as we have some breathing room :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAO-GxGNAhKrToX4FEwPzQ5RTY6XXUvxMSEemoz2YVxi7PD1X8w%40mail.gmail.com.

[José Valim]

On the other hand, one of the benefits of doing preloads is because we can parallelize them (and we do so in Ecto 2.0).

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CACZxBvQN%3D-c_-NS-pQqYz4pQv9D80KBWZc6XTNMzNTNezyeurQ%40mail.gmail.com.

[Boris Kotov]

Hi, I am just coming from the excellent elixir-getting-started curse.

And I was looking for good graphql implementation in elixir especially for the phoenix infrastructure.

I found that there are two competing projects which are targeting this technique: it's the graphql-elixir & absinthe.

So, for a newbie in elixir and phoenix its difficult to make a choice between these two.
I would say, that regarding the documentation feature coverage, absinthe feels definitely more promisingly. Good work!

But the graphql-elixir tend to be more popular, why? maybe because the most devs choose it as it comes first for the www.google.com?q=elixir+graphql query ;)

And heres my point, there are two teams working on the same issue, and competing each other spending energy. Instead of putting their bright minds into a solid solution which should be some kind of approved by the elixir/phoenix/hex team. (it's my freedom to say it!)

Ok, sorry for the long preamble, here is my question to the graphql folks, what do you like on graphql-elixir and absinthe, what are the benefits of each? Thank you guys

[Bruce Williams]

Boris,

(The following speaking as the creator of Absinthe and it's maintainer, along with Ben Wilson.)

First of all, thanks for the kind words.

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)

--

You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/89baa490-de92-4972-8333-ef3ca9219b4a%40googlegroups.com.

[Boris Kotov]

Hey Bruce,

thank you for the fast reply. I agree, that graphql is really "nice" for the client and really "complex" to handle it "nice" on the server (query composition, caching, views integration, maybe? React SSR on top etc.).

As I said, for me, Absinthe looks really good. I'll check out your slack chat for some of my questions.

Thx again,

Boris