GraphQL or REST?

I'm not really worried about boilerplate (my research reveals it's roughly the same), I currently have a (very incomplete) REST interface, but that was just for testing.

Also, the API has no real usage yet (I only use it for submissions) and it literally exists for the sake of having an API (so I don't need to write it later).

"it depends"

There are different implementations if graphql and some of them are quite lean to set up. I've grown fond of HotChocolate lately.

If you are on typescript for either the frontend or backend, graphql-codegen let's you make ts types out of the SDL which is neat.

@ltlian Well, for Go we have a number of options, the most similar to what you mentioned would be gqlgen, so that's not an issue. But would you be able to elaborate a bit on "it depends"?

Graphql should sit in front of one or more APIs. Using graphql as an API isn't really leveraging it's value.

@SortOfTested what do you mean?

@chabad360
Graphql isn't really a this or that proposition. It's more "this in front of that". Graphql's core proposition is this:

- provide a single schema query abstraction that sits in front of 1 or more interfaces
- the schema itself should absorb changes in the system it abstracts so it doesn't break consumers
- the graphql implementation abstracts coordination of parallel and nested calls to one or more locations and projections, ensures serial mutations.

Given that, whereas you can put that in front of a database or document store and treat it like an API, It's not designed to be an API. It functions more like an API gateway. It lacks features like granular validation and transactions, you have to write most of that yourself. Also, if you need to split your APIs at any point in the future, you'll be force to break consumers to do it, or spin another graphql in front that obfuscates the change.

A more paradigm appropriate approach is to build microservices (REST, gRPC, etc) and sit a graphql cluster in front of them to abstract away the complexity of interacting with them. The services provide the endpoints, and graphql provides the parallel coordination.

@SortOfTested secretly ctrl+c-ing for future questions on this.

It should also be clear why my short answer will always be "I really like it, but if you should USE it really depends". Then I just cross my fingers and hope they don't ask me to elaborate.

I was answering this question a couple of months ago and brought up pagination as one of the challenges. They said "pagination is always a bit of a headache. In rest also".

No. Ha. Let me try again. I don't think we are quite on the same page (edit: bonus pun not intended) here. If one of your nested relations has a nested relation that can (read: should (read: must)) paginate, you absolutely need to investigate how this works in the graphql standard and if you are able and willing to implement it - let alone if it's worth dedicating time to it compared to rest.

I've worked on three graphql projects now and none of them landed on a good solution for it because it was addressed after the data models were established.

I should do a proper implementation of it as a personal project just to have something to point at for next time.

@SortOfTested well, that's all good and fine, saying I'd be under utilizing its capabilities. But from the way you make it sound GraphQL doesn't really save you any code, you keep the underlying (REST) API, and GraphQL just provides a nice interaction layer. I'm asking about using it vs REST, which from what it sounds like, I'm supposed to use GraphQL in conjunction with REST? This project isn't exactly a good candidate for microservices, so that's not a viable option...

Also, considering my API is going to be changing/evolving a lot while the project is in it's early stages, wouldn't GraphQL provide an easier way to handle those changes?

@chabad360
Yes, it's not an API mechanism, it's middleware. It's meant to go between N different APIs (of any type, soap, rest, gRPC, xmlrpc, etc etc) and make them appear as one thing to a consumer.

As far as easier goes, I can write a secured API in spring boot, micronaut or dotnetcore way faster than graphql. Graphql can, on the other hand, be largely generated from swagger. It's much harder to define from scratch, and it's dragons are many when you get beyond basic operations.

Anyways, this is the Droid you're looking for:
https://blog.logrocket.com/5-reason...

@SortOfTested Thanks a lot for that, it helped clarify some of the things you mentioned. I guess I'll be going with REST then.

boollooocks

Use GraphQL

in fact, use Hasura

goodbye