I tihnk the more nuanced argument for GraphQL here isn’t that it’s impossible to parameterize REST, it’s just that everybody making their own ad hoc way of doing it is worse DX than having a spec for how to do so.

Yes, there are specifications out there that standardize on some of this, and that might work great for your use case! However it’s hard to beat GraphQL on the flexibility department.

Complexity analysis makes this a pretty solved problem in GraphQL as well. Certainly though I’d say it is more complex to support a public GraphQL API than a public REST API. Nightmare I think overstates the security situation though.

I’m not gonna weigh in here too much on the actual comparison bits but if folks have more questions about GraphQL I’m always happy to answer them as I can!

OpenApiSpex is the continuation of the Phoenix Swagger project, so you use it if you want a generic REST API documentation.

I’ve used about half a year ago in a new project and it worked flawlessly, used it with built-in swagger-ui behind an authentication wall. The only main issue I had was that I didn’t understand how to use the specs at first, however it becomes clear when you read from official open api documentation the format of the specs.

This argument sometimes comes from bad design of a REST API. See my answer on this other topic:

In resume, when designing a REST API endpoint for a resource nothing stops a developer from accepting a query parameter with the list of fields to be returned in the response, plus the list of sub-resources and their fields:

apibaas.io/some/endpoint?resource=posts:author;title;content,comments:author;content

Now, to group unrelated resources GraphQL as an advantage, but nothing stops you from having an API endpoints like this:

apibaas.io/some/endpoint?resources=categories:title,products:title;description;content;price,promotions:title,description,price,discount

Now, if you say that GraphQL query language looks better in terms of ergonomics I have to agree with you, but REST APIs are superior in terms of enforcing security via OpenAPI specs and prevent an attacker to dump a lot of data in a simple GraphQL request.

Put it simple GraphQL puts convenience over security due to its design. GraphQL is the nightmare of security teams and the dream of frontend devs.

I don’t like GraphQL either, unless it’s with a large team of separated front-end and back-end devs. In that case, though, I’m very happy with Absinthe. I used it for a client project 3 years ago and found myself pleasantly surprised more than once.

No API is free. You have to design it. There are a lot of little decisions like: how will you layout the various endpoints in code, how will you validate input, how will you control what is queried and returned, how will you share docs, and so on. A good GraphQL implementation, like Absinthe, could help with a good deal of this.