Swagger, gRPC or GraphQL?

You should probably consult with whoever is going to consume the APIs.

GraphQL is great solution, especially if you manage to make it “flat” and not too much of a nested / looped graph but it’s not being universally loved, especially by native/mobile application developers in my experience, and non-dynamic language programmers, who often rely on code-generation client libraries to consume the API.

gRPC very much similarly so, it’s often a choice that’s presenting a barrier, even bigger than GraphQL.

JSON API, with Swagger UI and documentation is more of a hassle to maintain on Elixir end, but it may be the familiar and easy to use solution by your API consumers.

I personally dislike GraphQL. In all my work in Elixir, Rust and Golang I have never seen one project where the fact that our backend is GraphQL-enabled has not led to a lot of boilerplate and double-schema writing (one in JS for the frontend and one in the backend language). Pragmatically and egotistically speaking only from a programmer’s point of view, GraphQL is a hassle and a fickle princess you have to handle with care in order for it to not fall over.

As much as I hate JS, I’ve only seen GraphQL development be almost frictionless in JS projects. Their ecosystem has it really well covered.

That being said, REST API or gRPC can be an even bigger hassle down the road, they you could start with a REST API relatively quicker than GraphQL (but not by much).

So if I have to pick the lesser evil I’d still go for GraphQL. It allows you do quite a lot and the stricter schema, while very annoying to maintain sometimes, pays for itself tenfold if your project lives to be at least 6 months old or more.

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.

Thanks @all for your input. Persuaded by the bitter realism of @dimitarvp, I’ll switch to GraphQL, the least bad option in 2023.

Still I dream of a world where I don’t have to maintain the schema in three places. Does anyone have experience with GraphQL or Rest/Swagger on the Ash Framework? Is this too good to be true?

image1167×608 56.5 KB

I guess everything is a preference. There is no “one size fit all” solution, but I personally love GraphQL and minimizing the data transferred (that is especially important when supporting mobile devices) and no need to write another endpoint just to provide another field.
In my very humble opinion, because of the schemas, it is easier to keep the naming consistency across the whole app.

I never used graphql for anything serious and at my previous project I declined using it because of a single fact: you just move the responsibility of data manipulation to the frontend. At the end of the day you write more code on frontend(mobile) in different languages that is more complex and harder to maintain, at least this is the way I see it in context of the applications I made and make.

GraphQL client complexity…

True. Curl and Wget are hard to beat. But for this app, I’m optimizing for backend developer experience.

Obviously, you are entitled to your opinion, but as I said, if you are supporting a big application you will constantly write APIs that do the same thing, just one more or less field to limit the data usage and end-user experience (because of loading time and memory usage if you transfer data that it is known no to be used).
The trade-off is that you shift the responsibility of knowing what information the front end needs to… the front end. Sounds reasonable to me. Moreover, I would personally refuse to work on a big application if it used REST because of the reasons above.

You are entitled to your own opinion and I respect that, even though I strongly disagree.

We are talking about different use-cases, but let’s not transform this into a conversation about advantages of types, because graphql is not the silver bullet.

I don’t want to be rude, but we work with what we got, at the end of the day if I can make a REST api work better on a project, based on multiple reasons, for example there is a mobile developer that is just a beginner, then that solution will always beat the philosophically correct solution.

Then I would go with rpc cals, give them the cookie and let them connect to your node and do the heavy lifting themselves.