Twitter OAuth Authentication with Elixir and Phoenix(headynation.com)
headynation.com
Twitter OAuth Authentication with Elixir and Phoenix
http://headynation.com/twitter-oauth-elixir-phoenix/
7 comments
Thanks for pitching in, jon-wood!
Can you elaborate what are the major wins with the GraphQL approach using Absinthe (in contrast to REST) which gives you the "superpower" feeling?
This is not a rhetorical question.
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.
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.
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.
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.
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.
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.
Got it. Thanks for taking the time to revisit and answer!
I hadn't seen Absinthe before. Thanks for pointing me in that direction.
I've been using Absinthe, which allows Phoenix to act as a GraphQL endpoint and it feels like some sort of superpower compared to building REST APIs in Ruby.