Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL: A Retrospective

verve.co

Post reply on HN
Print view View original

41–48 of 48 posts

Re: GraphQL: A Retrospective

#41

Post by he0001 »

013a wrote: post #18
ergothus wrote: post #7

I haven't yet had much luck in finding a GraphQL review that addresses my general concerns (I'm frontend). 1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved). Everyone says "oh, clients can do better caching", as if that's not true without GraphQL. Still, the ca…

The caching story in GraphQL sucks. Its pretty good with frontend frameworks like Apollo, but that's not a solution to the whole problem. Sure it works for your website/app (if you've got one), but it does nothing to offer caching for a generic API. Its easy to argue that the main advantage of GraphQL is to reduce overfetching fields on the data you need for your views. That's a great advantage. But how much of the p…

>Overall, I think GraphQL is fine. But I also believe what we'll slowly discover is that "Company X" simply fucked up their REST API, then will look to GraphQL to solve all their problems. And it might solve some of them, but then they'll have an even more complex system in place with even harder problems.

This! So very much this!

Re: GraphQL: A Retrospective

#42

Post by StevePerkins »

danr4 wrote: post #22

Off-topic if employees of the company are here: Friendly suggestion to work on the home page. I couldn't for the life of me understand what it is that company is about. The headline says NOTHING, and the paragraph after it is so confusing.

http://verve.co/our-products/

> VERVE EVENTS is the global market leader in word-of-mouth sales in the live entertainment industry. We use networks of advocates to sell products and experiences to their friends in exchange for rewards such as free tickets and backstage passes.

...

> POLLEN is a community of influential young people who are passionate about sharing the best events. We handpick Members and, through our tools and support, make it easy for them to share their passion.

...

This sounds like a hip, trendy veneer atop the concepts of affiliate sales, and offshore farms of fake review writers. I suspect that their landing page is vague by design.

Re: GraphQL: A Retrospective

#43

Post by Udik »

barrystaes wrote: post #37
meritt wrote: post #2

While this post is supposed to be about GraphQL, it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs and nothing unique to GraphQL. Their rule of "AVOID NESTING OBJECTS, JUST RETURN IDS OF RELATED OBJECTS" definitely is missing out one of the core benefits of GraphQL: being able to fetch related resources in a single request. Feels to me like they decided to switch…

> it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs Exactly my thought. From article, about REST API: > Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. Using GraphQL in a single API gateway, we would simplify the service landscape drastically.

Why didn't they simply use api versioning?

Re: GraphQL: A Retrospective

#44

Post by Udik »

Whenever I see descriptions of adopted solutions like this one, I always feel that someone is rushing towards a predetermined solution without having really checked the available options. You have a starting point and a set of issues. What are the minimal changes you can adopt to solve your problems, before deciding to use a new concept/ framework/ pre-packaged solution? In this specific case, two issues seem to stand out: the lack of a gateway, and the issue of breaking api changes. Both seem to be easily solvable without the need to jump to a completely different model. Maybe it was really the best choice, but I would be more convinced if the complete set of problems with the old architecture was clearly laid out and the possible options to solve them one by one had been clearly analyzed.

Re: GraphQL: A Retrospective

#45

Post by ergothus »

tirumaraiselvan wrote: post #32
ergothus wrote: post #7

I haven't yet had much luck in finding a GraphQL review that addresses my general concerns (I'm frontend). 1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved). Everyone says "oh, clients can do better caching", as if that's not true without GraphQL. Still, the ca…

2) Why do you think you can't do frontend business logic using GraphQL? It is going to be exactly the same as doing it with REST.

I apparently failed to make this clear - it's not GraphQL that causes that, but the libraries to use it on the front end (e.g. Apollo). These allow for front end logic, but it does NOT read as a simple case - you appear to be swimming upstream to do that. (Disclaimer: I've not used any such library myself. I've talked with GraphQL directly, which was definitely a bit more convoluted than REST directly, which is why people like libraries to streamline that).

The second point I apparently failed to convey is that these are CONCERNS of mine, not conclusions. I'm looking to find reviews that explore these so I can reach (preliminary) conclusions, but so far I largely see one-line reassurances. Which are great, and I appreciate it, but they don't leave me feeling like I've really done my due diligence on my concern.

Re: GraphQL: A Retrospective

#46

Post by d0m »

AaronFriel wrote: post #28

GraphQL is a curious beast. Developed by Facebook as part of one of its many attempts to solve a fundamental problem for engineers: how to loosely couple the frontend and backend, while maximizing query performance and allowing flexibility in the frontend. GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem. Their solution* is the blunt hammer that…

If you look at the graphql doc from the official website, this is what you get:

"GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data."

And as far as I'm concerned, this is exactly what I think graphql is and should be. It doesn't say anything about caching or solving the N+1 problem or ACID/consistency.

You say "GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem.". But the whole point of graphql is to just be a typed query layer and use whatever strategy makes the most sense for your application. I feel like it's like saying "I'm surprised that JSON took off even if it's not smart enough to do X"... where actually JSON took off _because_ it doesn't try to do all of those features.

Re: GraphQL: A Retrospective

#47

Post by ctulek »

AaronFriel wrote: post #31
ctulek wrote: post #29

Earlier quoted context omitted.

I didn’t understand why you have to use caching with DataLoader. I am also not sure about what you mean by inconsistency. The n + 1 query problem is usually solved by making two consecutive queries to the database. One for the root element and one for the total list of all edges, thanks to DataLoader. What is the problem with that?

Because you are now relying on consistency to be orchestrated in both the database and the dataloader instance(s). 1. If the dataloader isn't the sole service with database connections, the cache will be invalid when other services interact with the database. 2. Even if the dataloader is the sole mechanism for accessing the database, you have to figure out how to scale that to multiple nodes and maintain cache cohere…

I still don't understand what you expect DataLoader or GraphQL to solve for you.

The list of problems you mentioned are not what DataLoader/GraphQL are trying to solve. I am even not sure if there is an individual library that can solve these problems. The solution to them are at architectural level and requires more discussions than the decision to use GraphQL/DataLoader or not.

Re: GraphQL: A Retrospective

#48

Post by np_tedious »

sethherr wrote: post #34
013a wrote: post #18

Earlier quoted context omitted.

The caching story in GraphQL sucks. Its pretty good with frontend frameworks like Apollo, but that's not a solution to the whole problem. Sure it works for your website/app (if you've got one), but it does nothing to offer caching for a generic API. Its easy to argue that the main advantage of GraphQL is to reduce overfetching fields on the data you need for your views. That's a great advantage. But how much of the p…

Case in point, from the article: > Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles. There’s an easy solution to that problem, which is a versioned API.

Is it easy? Multiple api versions can be pretty annoying / tedious
Post reply on HN