I am interested in developing an api for a Single Page Application along the lines described here:
Anyone already made such an api / has pointers to projects that could help me?
Note: I am just a starting elixir / phoenix developer, worked myself through Dave Thomas’ and almost finished the phoenix tutorial.
4 Likes
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
5 Likes
Thanks. Jean-Jacques Dubray has some things to say about GraphQL in this overall interesting article btw: https://www.infoq.com/articles/no-more-mvc-frameworks
4 Likes
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!
7 Likes
Thanks for this link about the SAM architecture. This is a whole 'nother avenue I must explore now. Intuitively it feels right being reactive and functional…
2 Likes
A couple of reactions pointed to graphql. Never heard of it, but when I’m correct it is about the GET only. But for that part it looks interesting at first sight. I cannot find much criticism on the subject of graphql, except mr Dubray’s (https://www.infoq.com/articles/no-more-mvc-frameworks , look for keyword graphql). I would like to get more understanding of what the critique means. More people are struggling with this matter, see f.e. https://gist.github.com/idibidiart/49a095b6bc528638f34f . Can someone explain? Maybe you mr. Dubray?
1 Like
Hi, I recently published a working spa at https://github.com/akeating/peap that includes graphql. It’s likely you will need both rest and graphql in any non-trivial application. I delegate the rest api implementation to grapqhl internally, thus using graphql as api for both grapqhl and rest endpoints.
3 Likes
