Live data from Hacker News

I reviewed 1,000s of GraphQL vs. REST perspectives

konfigthis.com

41–48 of 48 posts

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#41

Earlier quoted context omitted.

You should have put a proper disclosure in the post to avoid speculation. Also it seems off to do all this research, and then instead of summarizing it properly, throw evewrything away and finish it with your own sentiment. I remeber there was a paper where the reserches asked students to implement the same API using either REST/HTTP, or GraphQL, and the conclusion were in favor of GraphQL. I would've added reviews o…

Fair points, I added a disclosure for clarity in future reference. That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting. Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.

What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL.

GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#42

Earlier quoted context omitted.

Fair points, I added a disclosure for clarity in future reference. That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting. Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.

What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL. GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

Why is this an anti-pattern?

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#43

My main takeaway: GraphQL moderately improves developer enjoyment (DevEx) by majorly increasing the cost of making production ready APIs. I've worked on bigger teams where the job was boring and there was plenty of spare capacity to improve DevEx. Spending a lot for a more enjoyable DevEx was worth it to retain good talent. They typically spent about 50% of their total capacity on DevEx and technical debt. Those team…

Depends how you use it. We use Hasura, and find this massively decreases the cost of making production ready API's vs traditional REST development.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#44

Earlier quoted context omitted.

What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL. GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

Why is this an anti-pattern?

> they expose the data model and copy it as-is in GraphQL.

> GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#45

Earlier quoted context omitted.

Why is this an anti-pattern?

> they expose the data model and copy it as-is in GraphQL. > GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

> they expose the data model and copy it as-is in GraphQL.

This isn't inherently an anti-pattern.

> GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

A) Says who? B) Why do we have to follow that specific dogma?

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#46

Earlier quoted context omitted.

> they expose the data model and copy it as-is in GraphQL. > GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

> they expose the data model and copy it as-is in GraphQL. This isn't inherently an anti-pattern. > GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other. A) Says who? B) Why do we have to follow that specific dogma?

Who says that spaghetti code and Big Ball of Mud are anti-patterns? ;)

Why not to expose SQL interafce or DynamoDB API directly to the client? ;)

While tools like AWS AppSync, Hasura, & PostGraphile accelerate initial development, the bulk of SW Engineering costs are adding new features & providing ongoing support and maintenance.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#47

Earlier quoted context omitted.

> they expose the data model and copy it as-is in GraphQL. This isn't inherently an anti-pattern. > GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other. A) Says who? B) Why do we have to follow that specific dogma?

Who says that spaghetti code and Big Ball of Mud are anti-patterns? ;) Why not to expose SQL interafce or DynamoDB API directly to the client? ;) While tools like AWS AppSync, Hasura, & PostGraphile accelerate initial development, the bulk of SW Engineering costs are adding new features & providing ongoing support and maintenance.

I don't expose SQL to the client because my client apps don't have good SQL support, my database server doesn't scale connections well and it would take effort to properly lock down the SQL permissions.

That said, there are uses cases where this might be a good pattern - e.g. limited distribution internal tooling.

Direct access to SQL is a great example of something that is not an antipattern. It's just one approach of many, with strengths and weaknesses.

In my use-case adding new features and support is the majority of eng work. We find Hasura is valuable here in reducing the cost of doing so - especially compared to traditional REST implementations.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#48

Earlier quoted context omitted.

Fair points, I added a disclosure for clarity in future reference. That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting. Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.

What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL. GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

(From hasura)

Came across this blogpost that happens to describe where something like hasura sits and how it decouples product dev (app + bff) from data api (microservice + db) dev.

Think of Hasura as a GraphQL BFD (backend for data) instead of a GraphQL BFF.

Post reply on HN