REST vs. GraphQL – A search for evidence on which is better • Hacker News Board

Re: REST vs. GraphQL – A search for evidence on which is better

#241

Post by collyw » Thu, Dec 17, 2020, 9:29 AM UTC

Aeolun wrote: post #212

collyw wrote: post #208

Earlier quoted context omitted.

> I think the opposite is true. GraphQL puts most of the onus on the client to know the data model, define their own queries, understand how to join data etc. REST-style APIs do all of this on the server side, and provide the most interesting query results directly. This is how I view graphql (despite not having used it). It seems better practice to keep the querying done in the backend and keep frontend for display…

It is really hard to do business logic in GraphQL. The language syntax is literally limited to ‘I want this data’.

That's exactly what SQL does. No one ever said it was hard to do business logic in SQL.

Re: REST vs. GraphQL – A search for evidence on which is better

#242

Post by infinite8s » Sat, Dec 19, 2020, 4:14 PM UTC

lmeyerov wrote: post #175

zachrip wrote: post #34

Earlier quoted context omitted.

I think REST is definitely playing catch up here though. A standard gql setup generally comes out of the box with type generation, web playgrounds, etc. Of course it's possible now with REST but I really think that gql helped push the state of the art in this space.

We get that out of the box w boring old django/sqlize we do happen to do more interesting things elsewhere (GPGPU, columnar streaming analytics, reactive frontend, ...), so like sharp edges when a 10X+ lift, but ended up backing up on this layer as it was adding complexity w immature layers vs what felt like similar perceived benefits from reliable boring stuff. it doesn't scratch all our itches, but the big ones are…

Where do you use the boring pieces in your stack? Mostly around CRUD management of metadata?

Re: REST vs. GraphQL – A search for evidence on which is better

#243

Post by lmeyerov » Sun, Dec 20, 2020, 3:02 PM UTC

infinite8s wrote: post #242

lmeyerov wrote: post #175

Earlier quoted context omitted.

We get that out of the box w boring old django/sqlize we do happen to do more interesting things elsewhere (GPGPU, columnar streaming analytics, reactive frontend, ...), so like sharp edges when a 10X+ lift, but ended up backing up on this layer as it was adding complexity w immature layers vs what felt like similar perceived benefits from reliable boring stuff. it doesn't scratch all our itches, but the big ones are…

Where do you use the boring pieces in your stack? Mostly around CRUD management of metadata?

basically!