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

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

471–480 of 721 posts

Re: After 6 years, I'm over GraphQL

#471

Post by eadmund »

hansonkd wrote: post #231
theptip wrote: post #228

Earlier quoted context omitted.

The canonical REST solution of query params to add nested fields gets you quite far: GET /myresource?extra=foo,bar sure you over fetch a bit if you have multiple accessors. But agreed, if you have highly nested data especially when accessed with multiple different query purposes then REST might not be the best fit. I think GraphQL has been positioned as a general purpose tool and for that I am with the author, REST i…

I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL

> Any more levels and you have now reinvented GraphQL

Sure, but reinventing the wheel can be good, particularly when the existing wheel technology is oblong, lumpy and constructed of stone and cheese.

I’m just bitter than GraphQL endpoints return 200 on errors. If you’re returning 200 on errors, then you’re not really doing HTTP; you’re just using HTTP as a substrate for some other protocol, in which case you might as well just open a port and serve that protocol directly and not pretend to be HTTP.

Re: After 6 years, I'm over GraphQL

#472

Post by andreimackenzie »

hosh wrote: post #393
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production. Though I guess you can do that with REST too. I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backen…

Assuming the query language for the graph DB you have in mind is declarative like SQL, I recommend templated queries. I have found this technique scales pretty well for query complexity, makes it relatively trivial to "get to the query" if something needs to be debugged in the details more easily outside of the app, and it makes performance-oriented optimization work far easier.

I've had my share of headaches with the various flavors of ORM and GraphQL and always come back to query templates, e.g. MyBatis in the JVM ecosystem or Go's template package. There is still value in abstracting this from the REST web service interface to make it possible to change the appdatabase connection without disrupting REST clients. It's possible to reuse parameter structs/classes between the REST client and DB+template client layers to avoid a lot of rote translation. It seems simple and repetitive, but actually saves time compared to the GraphQL/ORM complexity as apps & query complexity scale, in my experience.

Re: After 6 years, I'm over GraphQL

#473

Post by svieira »

AaronFriel wrote: post #429
hosh wrote: post #393

Earlier quoted context omitted.

Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production. Though I guess you can do that with REST too. I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backen…

This is a vague recollection, but I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint. The bundled frontend code is never given an open-ended SQL or GraphQL interface. And perhaps not coincidentally, React introduced "server a…

> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint.

I don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: https://engineering.fb.com/2020/05/08/web/facebook-redesign/...

> perhaps not coincidentally, React introduced "server actions" as a mechanism that is very similar to [the above]

Yep - there's also the Scala framework LiftWeb (https://www.liftweb.net/), the Elixir framework Phoenix (https://www.phoenixframework.org/) and of course the system we're using right now (Arc) that do similar things. Scaling these kinds of UUID-addressed-closures is harder (because the client sessions have to be sticky unless you can serialize closures and send them across the network between servers).

Re: After 6 years, I'm over GraphQL

#474

Post by mvdtnz »

hansonkd wrote: post #177
mattbrewsbytes wrote: post #140

Earlier quoted context omitted.

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

> With internal REST for companies I have seen so many single page specific endpoints. Gross

That's an established pattern (backend for frontend). Like all patterns there are trade-offs and considerations to make, but it's certainly not a priori "gross".

https://learn.microsoft.com/en-us/azure/architecture/pattern...

Re: After 6 years, I'm over GraphQL

#475

Post by tossandthrow »

eatsyourtacos wrote: post #305
tossandthrow wrote: post #238

Earlier quoted context omitted.

Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?

>Are you proposing just to add new field to a JSON response, even though they are not needed? That is exactly what OP is proposing and it makes total sense. More data != bad. Just ignore if you don't need it. For 99.999% of cases the bandwidth of extra data is entirely negligible. For business cases you just want to get things done. If the server has added more data, which is obviously relevant in some regard, you ca…

What decides what data to include?

Or are you just sending all data the client cloud possibly see over?

Re: After 6 years, I'm over GraphQL

#476

Post by ForHackernews »

burutthrow1234 wrote: post #397
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…

Sounds good to me. I'll do GraphQL for $250k.

Re: After 6 years, I'm over GraphQL

#477

Post by svieira »

datavirtue wrote: post #226
ComputerGuru wrote: post #188

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

It's analogous to a specific method in code. No idea why people go nuts over this.

I suspect that people don't think about it too hard and presume that they should have only one model - that is that their REST model should map directly to their DB model which should map directly to their internal domain model (the idea that there might be two-or-more-domains and not-all-of-them-are-public hasn't even yet crossed their minds).

When you realize that sometimes your REST model may be a view-model that maps to a different storage model optimized for online-transaction-processing, neither of which map to your internal domain model directly (there are adapters for that) _then_ you get somewhere ... but of course you then have to fight off the `transformToRestModel(transformToDomainModel(retrieveDbModel(theId)))` when the three models happily coincide for a time.

Re: After 6 years, I'm over GraphQL

#478

Post by awongh »

joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it.

Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql so you have options.

Re: After 6 years, I'm over GraphQL

#479

Post by rbalicki »

Folks on this thread should check out Isograph: https://isograph.dev and https://www.youtube.com/watch?v=gO65JJRqjuc.

GraphQL has a lot of advantages, the most important of which is data masking. In a properly structured GraphQL app, only the function that requested a field (i.e. included it in a fragment) sees that field. This allows many developers to move independently, without communication or coordination.

It's unfortunate, but there are lots of rough edges with GraphQL and it is hard to incrementally adopt, and so if you don't have enough developers (to have communication issues) and a team devoted to adoption, it might not be worth it.

Anyway, Isograph is a framework that seeks to take away many of those rough edges, while baking in stuff like data masking, etc. Y'all should check it out!

Re: After 6 years, I'm over GraphQL

#480

Post by garydevenay »

I admire the 6 year dedication (or architectural investment?). We were both jumping aboard that hype train in 2018, even talked about it in meat-space. I left that project in 2019 and never looked at GraphQL again, so didn’t make it as far you to the technical depths.

Something just never felt right about the client building the queries for me, I guess.

Post reply on HN