Live data from Hacker News

GraphQL: The enterprise honeymoon is over

johnjames.blog

201–210 of 241 posts

Re: GraphQL: The enterprise honeymoon is over

#201

> The main problem GraphQL tries to solve is overfetching. My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me. TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is muc…

I 100% agree that overfetching isn't the main problem graphql solves for me. I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem. For me what GraphQL solves as main problem, which I haven't got good alternative for…

> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

I've seen this this solved in REST land by using a load balancer or proxy that does path based routing. api.foo.com/bar/baz gets routed to the "bar" service.

Re: GraphQL: The enterprise honeymoon is over

#202

Earlier quoted context omitted.

> when a server receives an input object, that object will conform to the type Anything that comes from the front end can be tampered with. Server is guaranteed nothing. > GraphQL always prunes return objects to just the fields requested, which most other API tech doesn't do, and this can be a really nice security benefit. Request can be tampered with so there's additional security from GraphQL protocol. Security mus…

Expecting GraphQL to handle security is really one of the poorest ways of doing security, as GQL is not designed to do that.

Sorry, I made a typo:

Request can be tampered with so there's *NO additional security from GraphQL protocol.

Re: GraphQL: The enterprise honeymoon is over

#203
post #22

> The main problem GraphQL tries to solve is overfetching. this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL. In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, wh…

> overfetching is never such a big problem Wait, what? Overfetching is easily one of the top #3 reasons for the enshittification on the modern web! It's one of the primary causes of incredible slowdowns we've all experienced. Just go to any slow web app, press F12 and look at the megabytes transferred on the network tab. Copy-paste all text on the screen and save it to a file. Count the kilobytes of "human readable"…

Overfetching does not lead to those megabytes. And it has nothing to do with the enshittification process of a middleman like Amazon fucking over both customers and sellers.

Re: GraphQL: The enterprise honeymoon is over

#204
post #69

GQL was always one of those things that sound good on the surface but in practice it never delivers and the longer you're stuck with it the worse it gets. Majority of tech is actually like this. People constantly want to reinvent the wheel but in the end, a wheel is a wheel and it will never be anything else.

i do a lot of data shenanigans and it's just annoying to work with when some saas goof doesn't consider that orgs are in the business of warehousing the piss out of entire platforms worth of data that they are paying saas guys a million dollars a year for just so they can marry it together with other reporting. all roads lead to damn reporting. so if you want to woo clients but only have graphql then you should probably build some connectors they can use elsewhere they can easily retrieve all their data from. i straight up don't meet business analysts who use graphql to fetch reporting data. it's always me and my engineers sidequesting to make that data available in a warehouse env. my prob with graphql is it forces me to get intimately familiar with platforms i want to just plug into the butt of some object storage container so it can auto ingest into the warehouse and walk away. this is easy to do when the platform who knows their data and their data structure well serves up a rest api that covers all your bases. with graphql the onus is on me to figure out what the f all data i might even need and a lot of platforms have garbage documentation. so much fun since every service/app designs their db differently. no matey, postman is not the time or place for me to familiarize myself with your data model. i shall do that in the sql gladiator arena once ive ironically over fetched and beat the shit out of your graphql resolvers and stuck the data back in a database anyways. if im developing an apps or tools to interface with some platform graphql is fine but it ends there. in situations where i need to bring data pipelines online for my org its just annoying to work with. syntactically im annoyed, my engineers are annoyed, it just amuses me to no end that platforms dont know how big reporting is at orgs they seem surprised not everyone is developing some front end app to their "modular commerce solution" and sometimes they dont even know how to answer when we ask if theres anything we should consider because we're about to hang out at the ceiling of our allowed rate limits when we bring these data pipelines online. they seem surprised that we're interested in reporting, like wtf we pay you a million a year so we can do your whatever as a service thing of fkn course we'll be reporting on the data there. how else are we gonna smoke that proverbial value add on quarterly calls? graphql brings a query language over http. it takes a resolver that's well designed, configured and resourced. i'd rather just rawdog a sql query over the net and have postgres or whatever transpose that to json, return that and let me figure the rest out myself. ive never needed this exactness and freedom out of an api that graphql enjoyers love. i can take whatever there you throw at me and polish into the turd needed for the job, but i generally prefer vendors who have a well thought out and comprehensive and reliable set of rest endpoints. in that scenario its just easier for me to real time it into a warehouse and immediately push off to a stream or queue that populates a postgres instance if i need to build a high traffic web app. reporting needs and application needs are met and i dont have to don't need to do bespoke jujutsu sitting in a rest client and staring at json requests to determine what data i need before i architect out some one off gql query. i look at ton of data, graphql is the most overengineered and unintuitive way to review a lot of it.

its a data retrieval setup that specifically caters towards front end dev. i've done plenty of fe and i will design an app with whatever data when its needed when im building the front my headspace is completely impartial to whether or not im working with gql rest or a podunk db. so im here wondering why no one is just saying this: its nice and convenient when you're on the front, but its hardly a requirement to need a gql api. some like to think it solves for an organizational rift between front and backend devs, and that's just kicking the can down the road. im not sold on the empowerment of fe at the expensive of teams working well together. yeah isolate them more well never need to talk to fe again. great strat

since i happen to also work backend and on enterprise data i see a lot of angles that tightly scoped front end graphql enjoyers do not see and will likely never have to deal with ever. but we deal with it all the time, at least it's convenient for one of us. sucks that it isn't me

Re: GraphQL: The enterprise honeymoon is over

#205
post #204
post #69

GQL was always one of those things that sound good on the surface but in practice it never delivers and the longer you're stuck with it the worse it gets. Majority of tech is actually like this. People constantly want to reinvent the wheel but in the end, a wheel is a wheel and it will never be anything else.

i do a lot of data shenanigans and it's just annoying to work with when some saas goof doesn't consider that orgs are in the business of warehousing the piss out of entire platforms worth of data that they are paying saas guys a million dollars a year for just so they can marry it together with other reporting. all roads lead to damn reporting. so if you want to woo clients but only have graphql then you should proba…

@grok: summarise this post in two sentences.

Re: GraphQL: The enterprise honeymoon is over

#206
post #130

Earlier quoted context omitted.

Authz overhead for graphql is definitely a problem. At GitHub we're adding github app support to the enterprise account APIs, meaning introducing granular permissions for each graphql resource type. Because of the graph aspect, queries don't work til all of the underlying resources have been updated to support github apps. From a juice vs squeeze perspective it's terrible - lots of teams have to do work to update the…

I mean, the use of GraphQL for third party APIs has always been questionable wisdom. I’m about a big a GraphQL fan as it gets, but I’ve always come down on the side of being very skeptical that it’s suitable for anything beyond its primary use case — serving the needs of 1st-party UI clients.

Strongly agreed.

Re: GraphQL: The enterprise honeymoon is over

#207
post #166

Earlier quoted context omitted.

No it doesn't

Did you see the repo? https://github.com/kubb-labs/kubb Most of the commits and pull requests are AI. Issues are also seemingly being handled by AI with minimal human intervention.

I've had a PR on Kubb that was taken over by a human maintainer. They then closed my PR and reimplemented my fix in their own PR.

So, the project is human enough to annoy me, anyway.

Re: GraphQL: The enterprise honeymoon is over

#209

Earlier quoted context omitted.

You still require gql requests to deal with. There's pretty much the same amount of code to build in BFF as it is to build the same in GQL... and probably less code on the frontend. The value of GQL is pretty much equivalent to SOA orchestration - great in theory, just gets in the way in practice. Oh and not to mention that GQL will inadvertently hide away bad API design(ex. lack of pagination).. until you are left q…

Your response is incredibly anecdotal (as is mine absolutely), and misleading. GQL paved the way for a lot of ergonomics with our microservices. And there's nothing stopping you from just adding pagination arguments to a field and handling them. Kinda exactly how you would in any other situation, you define and implement the thing.

Yeah I love it when a request turns into an N+1 query because the FE guys needed 1 more field.

Re: GraphQL: The enterprise honeymoon is over

#210

Earlier quoted context omitted.

I 100% agree that overfetching isn't the main problem graphql solves for me. I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem. For me what GraphQL solves as main problem, which I haven't got good alternative for…

> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observa…

Doesn't even need to be a proxy, you can lay out your controller and endpoints like this just fine in most modern frameworks
Post reply on HN