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

611–620 of 721 posts

Re: After 6 years, I'm over GraphQL

#611

Post by randomdata »

hamandcheese wrote: post #607
RedShift1 wrote: post #593

Earlier quoted context omitted.

So GraphQL is bad because you didn't implement authorization, which you should have been doing regardless of the API technology you use?

I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API. In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default. In a typical REST application, it is enough to ask "does this user have permission to take this action".…

If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer.

In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started using it as a poor man's SQL, but that's not really what it is for.

Re: After 6 years, I'm over GraphQL

#612

Post by akshayshah »

grounder wrote: post #601
pants2 wrote: post #426

Earlier quoted context omitted.

Buf Connect or any RPC design really is great. I'm sick of REST too. No more endless discussions about how to make this endpoint the most RESTful or how to cram a feature into REST that doesn't fit. "Oh you need an endpoint to hibernate the server? Just POST a new Hibernate object to the /api/v2/hibernations service." No. With RPC we can just make a HibernateServer call and be done with it.

Can you provide a link where I can learn more about "Buf Connect". A search gives me a lot of different results. Not sure what's official.

https://connectrpc.com

We just joined the CNCF, too!

Re: After 6 years, I'm over GraphQL

#613

Post by roenxi »

hackthemack wrote: post #564
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…

One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…

It isn't specific to software either. The root cause seems to be a large number of people who don't understand either the basic technique (like rest) or the alternate technique (like GraphQL) and so make the choice based on what the majority of people are talking about right now. They won't listen to you, because there is one of you and usually 5-10 people talking about the latest big thing. They make the decision using that literal metric.

That simultaneously makes marketing value and drives a lot of silly decisions. Not much to be done though, humans are human

Re: After 6 years, I'm over GraphQL

#614

Post by zamalek »

> Rate Limiting... OOM... There is no REST equivalent to this attack of this severity.

Yes there is, simply throw JSON such as `[[[[[[...` at the server. You probably don't have to get into parsing though, nearly all C# (and Node, and Ruby, some Rust even) assumes that memory is, in-fact, infinitely large and just throw network input into a precisely-sized buffer. Just upload a few GB of nonsense to an API endpoint, bonus points if you omit Content-Length.

Re: After 6 years, I'm over GraphQL

#615

Post by hamandcheese »

randomdata wrote: post #611
hamandcheese wrote: post #607

Earlier quoted context omitted.

I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API. In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default. In a typical REST application, it is enough to ask "does this user have permission to take this action".…

If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer. In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started…

In the wild, I primarily have seen graphql implemented instead of, or perhaps next to, REST. Not on top of REST.

I'm not sure what you mean about a poor man's SQL. Whether it's backed by micro-services via REST, or just a graphql API in a single app, the value prop for frontendbackend communication is the same. It's not "using graphql wrong" to not have a micro service architecture.

Re: After 6 years, I'm over GraphQL

#616

Post by wtetzner »

zamalek wrote: post #614

> Rate Limiting... OOM... There is no REST equivalent to this attack of this severity. Yes there is, simply throw JSON such as `[[[[[[...` at the server. You probably don't have to get into parsing though, nearly all C# (and Node, and Ruby, some Rust even) assumes that memory is, in-fact, infinitely large and just throw network input into a precisely-sized buffer. Just upload a few GB of nonsense to an API endpoint,…

I dunno, the REST endpoints I've worked on enforced a maximum message length.

Re: After 6 years, I'm over GraphQL

#617

Post by noduerme »

Xcelerate wrote: post #58
noduerme wrote: post #9

Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.

> the idea of exposing queries from the client directly to the DB is totally bananas I don’t necessarily disagree but going to play devil’s advocate here on this common foundational viewpoint. Why is this bad? In fact, why not expose the DB directly to the client? “Additional layers” and “don’t explain DB structure” is security through obscurity. If a DB manages access control directly (field-level or partition-level…

I'm not saying security by obscurity is true security. It's one thin layer, though.

>> If you move the responsibility for security to the DB itself (other than authentication)

And what about all the possible access levels within your auth? Should every DB view have to check a user table to authenticate that the viewer has the priority level to select on it? If it doesn't, all I need to know is the name of a view I'm not supposed to see. What happens if you add a new security level... you change every single view definition? What if your auth + user levels are in a completely different DB in another time zone? Why put that burden on the DB if you get flooded with bad queries from hundreds of clients? That's why I say it's crazy, instead of writing an API endpoint that runs auth first and knows which views or tables are accessible from there and to which users, all in one place. Yes you have slightly more work conforming the client data definitions to whatever is returned from the API, but that seems like a very small price to pay to put all your security and filtering/validation in an easy-to-read middle layer. Of course you should use views and DB perms, but those are not sufficient if someone steals a login or session unless there's a middle layer checking their IP and hash and potential double-taps and lots of other markers that it might be a rogue query before it goes to the database.

Re: After 6 years, I'm over GraphQL

#618

Post by randomdata »

hamandcheese wrote: post #615
randomdata wrote: post #611

Earlier quoted context omitted.

If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer. In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started…

In the wild, I primarily have seen graphql implemented instead of, or perhaps next to, REST. Not on top of REST. I'm not sure what you mean about a poor man's SQL. Whether it's backed by micro-services via REST, or just a graphql API in a single app, the value prop for frontend backend communication is the same. It's not "using graphql wrong" to not have a micro service architecture.

Using it as a poor man’s SQL was addressed, but using it that way doesn’t mean that’s what it is for.

Re: After 6 years, I'm over GraphQL

#619

Post by parentheses »

GraphQL is an opaque layer that is not necessary in the truest sense.

The lie is that it makes things better. 100% of the time that I add an unnecessary thing to a project in the name of "it will make things better", it never did.

It's the old new-shiny, so here we are lathering on our dislike, which I feel is totally normal and expected. There's a new new-shiny around somewhere and a few years from now, I'll see articles like this one about it.

Having not yet read the comments, I plan to enjoy them thoroughly, I love a good hate-post about software I myself don't like. :)

Re: After 6 years, I'm over GraphQL

#620

Post by aprilthird2021 »

parentheses wrote: post #619

GraphQL is an opaque layer that is not necessary in the truest sense. The lie is that it makes things better. 100% of the time that I add an unnecessary thing to a project in the name of "it will make things better", it never did. It's the old new-shiny, so here we are lathering on our dislike, which I feel is totally normal and expected. There's a new new-shiny around somewhere and a few years from now, I'll see art…

I'm curious about this. Do you think GraphQL makes things worse in its intended use case: allowing different clients to control how little or how much data they pull.

I have been, like you, baffled by places that insist on using GraphQL for a biz software website that they barely support on mobile, or an app-only product with limited to 0 web support. But for situations where you want both a robust mobile app (sometimes multiple), and a robust web app (sometimes multiple), I don't know if there's a better solution that keeps the frontends and one true backend decoupled as well?

Curious what you say or what I may have missed for this scenario.

Post reply on HN