When to choose GRAPHQL instead of REST for mobile apps?
1 Like
The two places where I think GraphQL really shines is:
-
Frontend and backend team is kind of separated. Can make it easier for them to work more decoupled (for example frontend can skip fetching one field no longer needed without having to wait for the backend team to remove it and backend can add new fields without having to wait for frontend).
-
You fetch similar data in many places but in different formats. So you might need all fields in one place and in other places you just need some of the fields. Instead of overfetching or having lots of extra endpoints graphql makes it easier since you can fetch what you need all from the same endpoint.
Big negative for me is that graphql is harder to cache and a bit more complex to setup (both frontend and backend) compared to REST. So if it is a simple app (in the sense that it doesn’t fetch a lot of different stuff everywhere) I go for REST but if it is a complex project I might go for graphql.
10 Likes
Definitely harder to cache. I would almost never use graphql personally. I think automatic documentation generation and client generation + rest + a little json API could cover 90% of uses cases.
8 Likes
Yeah, hard agree here. Nowadays you can compose a good OpenAPI file and you get an awesome interactive UI with which you can browse your REST API. Not to mention that your openapi.yml (or openapi.json) can be used to automatically generate clients for your API as well.
GraphQL I’ve mostly seen defended by frontend teams that find it easier to work with because they are its consumers. For the backenders it’s definitely extra work.
One thing I’ll absolutely give GraphQL props for however is – good detailed data schema. We need more of that, like literally everywhere.
10 Likes
Absinthe is pretty quick to setup, I just haven’t found inspiration for graphql yet, despite working with it for a while now.
2 Likes
I worked with Absinthe at least 4 times but it was always high-maintenance for me. Business and tech leadership constantly needed changes / additions / deletions and the GraphQL benefits almost never materialized.
5 Likes
not strictly related to mobile apps, but i might prefer GraphQL over REST when:
- i need elastic web interface/frontend to database/data store.
- i am not looking for an interface to business code.
- i am not after very tight controls over data going in and out.
2 Likes
I’m not an professional Elixir dev but I currently work as dev in NodeJS app that uses GraphQL for web app. My company decided to outsource mobile app development. Decision was made that mobile will use REST API. What a mistake it was. So many hours lost because we chose REST. Having second GraphQL endpoint just for mobile would have saved us because GraphQL uses schema for the API. It would have caught so many problems this outsource company was making instead of us having to point out these problems.
I would only use REST if you want to have an API customers would call by themselves.
If I would be developing with Elixir I would really look into LiveView if it fits your needs. I think it should fit most interactive web app development needs that don’t need offline capability. Because by using it you wouldn’t have to write any kind of internet facing API at all saving you lot of dev time.
3 Likes
I like GraphQL for the ease of traversing related/associated data. I like that I can define a User object once and that’s it. And that it’s smart about when it needs to hit the db and when not.
Also, we very strictly use Dataloader so we never have n+1 issues. And I’m not sure, but I was under the impression that Dataloader could also aid in automatic concurrent loading of data.
We only use GraphQL for read only data though; no mutation API at all.
4 Likes
A REST API can also give only the fields you need if coded accordingly. My REST APIs will accept this https://apibaas.io/endpoint for a response with all the fields, this https://apibaas.io/endpoint?fields=a,b,c,d for a response with only the specified fields, or https://apibaas.io/endpoint?except_fields=e.
A REST API can also aggregate results from several entities if you want, you just need to code accordingly.
Developers just need to have an open mindset and not blindly follow the herd. Also, follow API design first approach and use the tools at your disposal to design the API with OpenAPI specs. After you are happy with your API design give it to your consumers and address their feedback in the specification before you start to code the implementation, and repeat this as many times as needed until the API specification is beneficial for both the developers implementing it and the ones consuming it. During this API design first process you will discover many issues with your initial idea to solve the business requirements, thus saving you from discovering them after having already some thousands lines of code written.
8 Likes
The Chapter 1 of book “Craft GraphQL APIs in Elixir with Absinthe” explains this problem very well. You can read it.
In summary, it:
- allows the users of API (frontend developers, mobile app developers, etc.) to describe the data structure that they want, no more overfetching or underfetching:
- overfetching - downloading unnecessary data
- underfetching - a specific endpoint doesn’t provide enough of the required information. The client will have to make additional requests to fetch everything it needs
- allows the creators of API (backend developers) to focus on data relationships and business rules instead of implementing and optimizing specific endpoints:
- no more annoying user input validation
- no more limited flexibility of query parameters
- no more endpoints which are similiar but return different data
- …
GraphQL solves above problems. If you are facing these problems, consider to use it. Or, you don’t need it, maybe.
2 Likes
The schema is the selling point. It makes client API generation so easy.
4 Likes
In a REST API you have OpenAPI specs that when done properly (follow always design first approach) will allow you to:
- auto generate client SDKS (client API generation)
- auto generate mock servers (frontend team can work in isolation of the backend team)
- create automated tests for contract acceptance between client and server
- automate validation of incoming requests against the specification. This is huge from a security point of view. If the request isn’t in the format allowed in the specification you can refuse it, thus making it a lot harder for attackers to run fuzzing tools against your API in order to breach and exploit it.
- automate user input validation.
7 Likes
Same goes for OpenAPI but I’ll agree that GraphQL gives you more typing info which is invaluable.
I am not against GraphQL at all, I like its idea but in practice it’s been extremely tedious to constantly maintain and evolve literal hundreds of records / endpoints. And as mentioned above, I worked in teams with very dynamic and evolving requirements. GraphQL is… shall we say, not very applicable to projects that are constantly 10 test breaks away from being a prototype/MVP again. It seems very good for more mature projects.
I wish we had a much more compact and more comprehensive IDL and that’s actually universal… I’d really like to work on that before I retire (I have good 10-20 years in me still but the burn out and the mental resistance to straining my brain much further is already in place, for the better or worse).
4 Likes
Off topic but, man… this hits too close to home… 
I think I’m right there with ya.
2 Likes
My 2c are that if I am building a fully featured REST API, I would build it on top of GraphQL. Depending on the audience, GraphQL can be overwhelming (especially if you adopt advanced conventions like relay). However, GQL has a lot of benefits as an intermediate layer between REST and your business logic.
In practice, your REST layer would call a GQL query/mutation. You can leverage GQL’s resolvers for serialization, backwards compat for changes in business logic, N+1 is handled through Absinthe helpers / dataloader, and “expanded” REST fields are just conditional fragments on a query. A simple utility can convert GQL errors nested in the response into HTTP error codes. So your users are calling REST urls, but it’s actually GQL under the hood. And then, of course you could expose your GQL endpoint as well…
Interesting, caching has always been very straightforward for us. Our resolvers look up values in the cache first, then hit the data source. I’ve never understood the caching critique with GraphQL 
In the more general discussion: as someone that’s spent most of their career building the backend for one or the other I’m happy I’m working on a GraphQL service, and in Absinthe 
Still one of the best libraries I’ve used. The idea that every field in an API is backed by a function, and a query represents a sort of composition of them, is very easy for me to reason about.
I can see how the type system could become onerous if you’re in a constant state of flux though, I’ve heard people say similar things about typed languages.
1 Like
It’s about HTTP level of caching e.g. people want browsers or middle boxes to cache HTTP requests with an exact combo URL + parameters + cache headers.
Personally that doesn’t bother me much but I can see their point. I’m more worried by projects in flux as you mentioned – was hit by that and GraphQL left a sour taste back then. For more stable projects it’s very good however.
Ah I see. Apollo’s caching is pretty cool client side, and I think implementing your own caching in the backend is quite straight forward, but I also agree nothing beats the simplicity of wanting /foo/bar/baz to be cached with (effectively) zero effort.
