When to use GRAPHQL over REST?

The two places where I think GraphQL really shines is:

1. 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).

2. 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.

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.

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.

Absinthe is pretty quick to setup, I just haven’t found inspiration for graphql yet, despite working with it for a while now.

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.

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.

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.

I guess graphql fragmenet could be useful for caching. GraphQL fragments explained - LogRocket Blog

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.

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.