Hacker News new | ask | show | jobs
GraphQL at PayPal: An Adoption Story (medium.com)
9 points by arberavdullahu 1759 days ago
2 comments

As someone who is exploring a GraphQL "migration" for a rather large project, I'm interested to hear more about the issues in practice from people who've had to work in GraphQL environments on long timescales. I see a lot of the pro-GraphQL people talking up the advantages but never really the drawbacks.

I've had some concerns about GraphQL in the past when it was first coming up, but they look to be mostly addressed in some way shape or form. For example, using a CDN is now viable without hacks if you utilize something like Apollo Persisted Queries. Most of the research I've done on the topic recently has come up with a lot of outdated criticisms.

On that note, it almost feels as if people wrote off GraphQL in the beginning and have largely ignored the developments since. The people already on board the train seem to write more to an existing audience of users rather than people looking to get in.

> I see a lot of the pro-GraphQL people talking up the advantages but never really the drawbacks.

I tend to distrust any advocacy of a piece of tech that doesn't discuss at least one trade off. Engineering is all about tradeoffs.

> Avoid multiple round trips: Often, in order to call one endpoint that required a certain parameter, such as /getProfileById/{id}, we would have to call additional endpoints as a pre-req, such as getUser{username} to returnparameters such as id. This was a problem because we were making multiple round trips to fetch one piece of information. GraphQL helped solve this problem because it allowed us to fetch everything we need in one round trip.

Why not add another URL? /getProfileByUsername?

Nothing stops you building another layer of endpoints to service your frontend.

I read this as user & profile are two separate resources. With a standard REST API, calls are tied to a specific resource.

> Nothing stops you building another layer of endpoints to service your frontend.

They could've added a new endpoint for that specific usecase but I'm assuming they've simplified their actual needs to this one example.

Why not use /getProfile?id=something in the first place?