[jon-wood]

There's a few factors leading to that. Partly it's just Elixir and Ecto (the ORM used) being incredibly expressive.

Specifically with GraphQL it's the combination of it being self documenting, which allows UIs like GraphiQL to make it really quick to get going, and the fact you end up defining the structure of your data, rather than a few specific ways to query that data. Using that you can then query for whatever you need, wherever you need it, and you're able to compose queries really quickly.

[sahrizv]

Agreed on all counts.

However, I was more focused on the comparison with building REST APIs in Ruby. I wondered if using Absinthe to wire up all the GraphQL schemas and resolvers was a better experience in itself compared to building APIs the traditional way.

Or maybe it's a tradeoff which resolves positively in favour of GraphQL when a more expressive API is required in contrast to traditional REST when a limited API is required.

An "expressive" API as used above can be roughly understood as one with relatively large number of unique API endpoints.

[jon-wood]

I think you're about right. At least for now if I had a super simple API I'd just use Phoenix direct, but if you've got lots of inter-related objects which you're likely to query in interesting ways GraphQL makes a lot of sense.

Wrapping it all in Absinthe has been amazing for productivity once I got over the initial hump of getting my head around how it all fits together. Being able to quickly extract things like `resolve find_by_id(App.ModelName)` is incredibly refreshing, and there's very little messing around with data being provided by the client.

[sahrizv]

Got it. Thanks for taking the time to revisit and answer!