My experience with GraphQL has been with Absinthe in Elixir and it has been great. Custom REST endpoints can spiral into an inflexible mess with way too specialized DB queries built for each endpoint, while with GQL you can stitch different resources together on the frontend easily in one go. Of course, if you’re not careful you may get into N+1 issues, but there are solutions such as Dataloaders. Avoiding malicious queries sounds like a potential issue but as some comments have also pointed out, there are mitigations similar to e.g. rate limiting you also have to do on REST endpoints anyways.
GraphQL kinda sucks
401–410 of 448 posts
Re: GraphQL kinda sucks
#402> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
> some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
Please don’t use maps in API responses. Rarely do they map well and in all cases you can instead use a list of objects which is substantially easier to parse.
Re: GraphQL kinda sucks
#403Earlier quoted context omitted.
You haven't actually described any of the unique parts of GraphQL though. Generating a typesafe API whose schema is defined in a single place is trivial with an OpenApi spec and a client generator What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it.
> What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it. I mean, yes, you can technically write any project in C if you're smart and dedicated enough, but data scientists still use Python because it's easier to work with for the things they need to do. The fact that GraphQL is inherently safe, while REST is inherently…
I think it is the other way around. REST inherently only offers, what routes you implement, nothing more. In that sense it is "safe". There are frameworks like "Rocket" in Rust, which make things typesafe from the moment a request arrives at your route's handler. While GraphQL requires you to implement who can access what, because you allow the frontend a lot of freedom to formulate queries. This is inherently unsafe.
Perhaps we are talking about different kinds of "safety" or "aspects of safety"?
Re: GraphQL kinda sucks
#404Earlier quoted context omitted.
One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference. GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes…
Saving bandwidth is really not the actual super power. The main advantage is being able to save network requests by fetching all required data in the same request.
Agreed - REST APIs can include a field mask or similar for sparse selection on a single entity but you'll still need several requests to fetch fields on related entities.
Re: GraphQL kinda sucks
#405Earlier quoted context omitted.
Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style. I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users
Ancestors of your post are suggesting exposing entire DB schemas (I would assume mechanically). While that could also be the case in other protocols, typical an IDL is used to separately define the API layer. Of course it’s completely possible to generate a WSDL, etc. from a DB schema, in practice I’ve never seen it done.
My point is that passwords shouldn't be stored in the "normal" database where some clever architect might expose entire DB schemas to external access.
If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,
Re: GraphQL kinda sucks
#406Earlier quoted context omitted.
> We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if you’re un-authenticated/a regular user. I worked with a team that was going down a similar path. At some point it felt like they were reinventing REST on top of GraphQL with a strict set of predefined queries and result shapes. They hadn't gone too deep int…
One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference. GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes…
I just wanted to hop in and agree with you. I’m still think REST APIs have their place and are easier to work with. If someone had recommended GraphQL 5 years ago I would’ve been against it but Apollo is good enough that I think it’s a fairly safe choice for teams to make.
One thing you do need to watch for is preventing clients from doing stupid things by allow listing queries or implementing some sort of query cost analysis.
Re: GraphQL kinda sucks
#407Earlier quoted context omitted.
One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference. GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes…
Saving bandwidth is really not the actual super power. The main advantage is being able to save network requests by fetching all required data in the same request.
> The main advantage is being able to save network requests by fetching all required data in the same request.
This is not really GraphQL's selling point.
GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want.
The promise is that frontend teams simply put together a query and the server magically returns what they want.
Of course the people promising this magic just so happen to be the same people trying to sell you backend services.
Re: GraphQL kinda sucks
#408Earlier quoted context omitted.
I'm truly saddened to hear that this has been your experience throughout your career so far. It is not a universal experience. I hope you find a better managed shop soon that recognizes that it's easier to teach folks a tech stack than to teach someone to be a decent (or honest) person. Too many tech shops sabotage their culture and dozens of potentially great contributors in order to keep a few (or one) toxic contri…
Well said. I would also add that it is perfectly fine to have a list of red flags, and it is perfect fine to define your own bondaries. Graphql is a red flag for me too, as well is React and node.js, and even git to some extend. I love simplicity when designing web apps, their backend, their frontend and the deployment process in between. Although the tech is old , I came up that vue3+pouchdb+quasar is an amazing com…
This is like hating HTTP. GraphQL is a spec, not an implementation. GraphQL doesn't even mandate a network transport.
Solutions like Prisma, Hasura, and Postgraphile make GraphQL dead simple to implement compared to REST when exposing relational data.
AWS AppSync allows for a fully managed "serverless" experience as long as you're willing to do the schema creation grunt work and write Velocity templates. (FWIW, I'm not a fan, but it's still an option.)
Apollo (and Netflix DGS) are for when you're writing everything yourself, and you just need a simple API to tie in to the GraphQL spec in exchange for having to write/optimize/maintain it all.
The bright side to GraphQL is that you have choices, and when you present your "menu" of options, clients can grab what they need. Whereas on the REST side, any new requirements in calling requires direct interaction with the backend team and a new endpoint.
Honestly, server-based data access doesn't get any simpler than Postgraphile, but I totally see how you could get burned by an ill-fitting solution. However that is not GraphQL's fault. You might as well blame HTTP for problems you've had with Node/Express even though you've got other options in every programming language not to mention "pre-baked" solutions like Apache, Nginx, etc.
It's just a spec defining interaction, not a prescription for how that spec is implemented. It is also not a silver bullet. Right tool, right job, and all of that.
Re: GraphQL kinda sucks
#409Earlier quoted context omitted.
What tooling are you using that requires a massive amount of extra code? You need to define the schema and write resolvers, but that's sorta similar to what you might do in REST on the backend. On the frontend, you have a choice to use some of the heavier libraries that support all of the features (like subscriptions) - but otherwise, you can just POST a gql query to the server and it will return a blob of json, whic…
Why use graphql at all if you are going to use it just like a traditional REST api? You don't get much of a benefit from the client selecting which fields it wants, the backend probably fetches the entire DB row anyway so why not just send the whole thing over? The limitations of the query language make code size explode the moment you step outside simple toy examples. It doesn't have any concept of a JOIN, or of the…
You use graphql when you have many consumers of your data, whether other teams at your company or external data partners (which is how my team uses it). What it does is make it so that you don't have to provide a bunch of custom endpoints for these users, they can get exactly what they need without your help. You're also able to get performance gains dependent on the implementation.
Our code size for our graphql endpoint has remained totally unchanged for the past couple of years. It took only a few files (of admittedly complex code) to automatically set it up so that it would automatically provide all models via the graphql schema (and a separate permissions implementation restricts access at each level of the schema). It updates automatically whenever we add new models or permissions. This is built on top of Rails and the graphql gem.
Re: GraphQL kinda sucks
#410Earlier quoted context omitted.
Hasura seems to be fine which we use internally in our company, though to be honest I don't do any complex queries and I don't think anyone is doing aggressively nested joins.
I think that can be part of the problem: if you use it for a few things which make sense, you get used to it and everyone thinks it's pretty solid after a while and probably starts using and likely exposing it in other areas. Then you get someone new writing different code or a clever attacker and it turns out there was a lot of room to expose unintended data or create performance issues.
I don't think hasura allows unbounded queries by default? I'm not 100% sure though, I didn't set it up at where I work.