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

401–410 of 721 posts

Re: After 6 years, I'm over GraphQL

#401

Post by marcosdumay »

klibertp wrote: post #367
marcosdumay wrote: post #318

Earlier quoted context omitted.

The modern web development practices are just insane. The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cra…

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

If you absolutely need 2 people for that, they should be side by side.

But yes, that break-down of the problem is insane. People artificially split an atomic problem in two, and go create all of that extra craziness to try to solve the communication problem they made.

And then people go and push UX and UI tasks into the frontend developer, and ops tasks on the backend since them are there... What is insane again, because those are really incompatible tasks that can't be done with the same mindset.

And since it's standard, backend tools won't support the frontend and the other way around. So the insanity gets frozen on our tooling.

Re: After 6 years, I'm over GraphQL

#402

Post by suzzer99 »

aaronbrethorst wrote: post #166
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…

Harder to get a promotion when you’re doing something that’s old, boring, and just works.

Especially if your job title has "architect" in it.

Re: After 6 years, I'm over GraphQL

#403

Post by mattbrewsbytes »

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…

If an app's API requires more than a couple of nested structures then, without knowing the specifics of the domain, I would venture a guess at a poorly defined data model is the issue vs. API technology.

For example, a lot of times people build out nice normalized table structures for online transactional apps. The UI/UX is pretty straight forward because end users typically only CRUD an object maybe a couple nested objects at a time. The API's are straight forward as well, likely following single responsibility principles, etc. Then comes along requirements to build UI's for analytics and/or reporting types of things where nearly the entire schema is needed depending on what the end user wants to do. Its the wrong data model for doing those types of things. What should be done is ETL the data from the OLTP schema into a data warehouse style schema where data is de-normalized so that you can build reporting, etc.

Re: After 6 years, I'm over GraphQL

#404

Post by hansonkd »

realusername wrote: post #380
hansonkd wrote: post #366

Earlier quoted context omitted.

GQL you would only care about if someone removed a field not if someone added a field. How would adding a field change existing GQL calls return? Doesn't make sense. Also, Its about 1 line to set up CI to extract all GQL queries from a typescript project and do static analysis to check against the schema. But again you only care if someone deletes a field, and even if you have to delete it, at least the GQL schema ha…

Deleting things happens all the time though. Yeah sure you can make it work with anything if you spend the extra effort but the ownership really isn't as defined as in REST. Is there code which have fuzzy or no ownership? Are there changes which affect other teams? Suddenly those became much harder questions to answer.

Actually deleting happens rather rarely compared to adding.

Its much easier to trace and debug what teams are using GQL fields than REST. What if one team is piggy backing on another teams exising rest endpoint and you dont know? same problem that would require some analysis of all code calling and endpoint to determine if a field is safe to delete. GQL makes this much simpler than REST.

Re: After 6 years, I'm over GraphQL

#405

Post by hansonkd »

smaudet wrote: post #384
hansonkd wrote: post #285

Earlier quoted context omitted.

> This is akin to saying that "directly exposing the database is easier Far from it actually. I am saying that in practice the data and queries that you perform on your Database actually tend to stabilize and you add less and less as time goes on. By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use, you have to do less and less backend work when compa…

> By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use Sure, so you are just filtering raw database access then. That doesn't make it any different - and, you still need to approve and filter these queries, so what exactly have you saved? I.e. either the front end engineers can change these filters, or not, so it amounts to the same thing in the case t…

You are bouncing back between it is ony for startups and it requires enterprise level maintenance. It can be used easily for both.

> It still comes down to, if you can achieve 99% of the same thing with autogenerated REST apis and a couple page specific apis

Because you can get 100% by autogenerating GQL APIs and 0 page specific apis.

Re: After 6 years, I'm over GraphQL

#406

Post by LeonenTheDK »

mattbrewsbytes wrote: post #140
atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

> 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…

> and most likely a lot of the software we write will cease to be running in a decade

If only that were true in my experience.

Re: After 6 years, I'm over GraphQL

#407

Post by hansonkd »

arp242 wrote: post #361
hansonkd wrote: post #197

Earlier quoted context omitted.

Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.

This is like, an hour per endpoint. For maybe 30 endpoints (high figure for many apps) throughout the lifespan of your application. But let's say 3 hours: you're talking about 90 hours in total, over a period of 2 or more years. It's really not that much. And GraphQL isn't free either; you need to actually implement that. It pervades your entire stack, too – it's not something you can just "put on top of it". I think…

An experience engineer knows that a change that takes hour turns to days when a team is running at scale and needs to have CI approvals etc.

Why waste any time?

> And GraphQL isn't free either; you need to actually implement that

Rest isn't free. You have to actually implement also that and end up with a more limited API.

GraphQL libs in Python are equally as complex as the FastAPI etc..

Re: After 6 years, I'm over GraphQL

#408

Post by randomdata »

hansonkd wrote: post #398
randomdata wrote: post #368

Earlier quoted context omitted.

Nobody said you should expose your database to the outside world. Do you not understand the difference between APIs and services?

You said > The database will already have its own API Where is this API coming from? You have to build it. I'm saying you should make those APIs graphql apis though a language framework and not REST apis because GQL consuming GQL is much better than GQL consuming REST.

Someone has to build it, but as long as you are using a popular DMBS the work is no doubt already done. All you need to do is stick your application-y bits in the middle – same as you have to do with GraphQL. Computers aren't exactly magic. It's all just 1s and 0s at the end of the day. You can do just about anything and make it work. But there are tradeoffs to different approaches. If GraphQL is the best choice for working with databases, why don't DMBSes use it natively?

Re: After 6 years, I'm over GraphQL

#410

Post by suzzer99 »

asdasdsddd wrote: post #346
hot_gril wrote: post #338

Earlier quoted context omitted.

People need to stop judging the viability of something based on how satisfying it feels to use it in a toy project. When time is money, you'll see what really works. At least GraphQL supposedly works for Facebook, and I tried it out before deciding it wasn't a default. I never even bothered with MongoDB. I've had to repeatedly veto using both in projects, cause someone thought it'd be cool and thought that was a good…

GraphQL works when you have an army of engineers that are able to solve all the perf issues

Everything works when you have an army of top-flight engineers.
Post reply on HN