definitly agree.
If it's true, opening up the database port would be more worthwhile.
GraphQL kinda sucks
441–448 of 448 posts
Re: GraphQL kinda sucks
#442GraphQL is amazing. It always lame to see someone using wrong tools for tasks, even in carpentry. Same here of course, it's not bad, they just try to plane boards with saws, and you blame the saws
Re: GraphQL kinda sucks
#443I've only used GraphQL at my last two gigs, and didn't work with it full time. So there's a massive grain of salt. I think GraphQL is _mostly_ fine as a technology, but it seems incredibly easy to misuse and abuse. Particularly the fact that you can write arbitrary resolvers for specific fields and include any amount of business logic you like. It blurs the line between GQL being an interface to your API and actually being the API, and invariably it seems that too much logic gets put into resolvers because it's so easy.
As far as I can tell, one of the best ways to use GraphQL is as a sort of RPC framework. At which point, my question becomes why not just use an actual RPC framework? Personally I find the field filtering and reduced network I/O to be overblown. Anecdotally, most of the GQL queries I've seen request HUGE amounts of data up front to reduce the number of overall requests that need to be made. Obviously not saying that's everyone's usage, but in my experience GQL has never really been much of a value add.
Re: GraphQL kinda sucks
#444Earlier quoted context omitted.
It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses with GraphQL, but this completely achievable with standard REST APIs as well.
Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API, and there are some systems that do something close [0], but if you do it’s probably a less friendly syntax than GraphQL and has all the same problems as GraphQL regarding performance and rate limiting. [0] A very simple convention for including nested resources in a JSON API: https://www.jsonapi.ne…
Reminds me of http://odata.org/
Re: GraphQL kinda sucks
#445Earlier quoted context omitted.
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.…
I know I can make an API endpoint in Rails equally as fast as writing a query in GraphQL and the code needed to use it. I don't really buy into GraphQL yet since I have not come across a strong enough advantage of using it in my carrier. Although I do see the advantage of basically being able to run SQL through the browser. Unfortunately it is just one of may technologies over hyped by JavaScript developers.
Re: GraphQL kinda sucks
#446Earlier quoted context omitted.
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.
Yes that is the one strength I think GraphQL has that should be undeniable even though I am not a proponent of GraphQL myself.
Re: GraphQL kinda sucks
#447Earlier quoted context omitted.
Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem. To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder ( https://typed-graphql-builder.spion.dev/ ) and I can think of several ways the language could've been designed to make it easier to write type…
> I can think of several ways the language could've been designed to make it easier to write typed query builders. Would you like to share them? Have you tried submitting your suggestions to the GraphQL core team?
Even if I did share them, its too late for GraphQL to make that change - they are design decisions and people probably already rely on them
Here is a few:
- Less fine-grained field selection - allow for fields selected by default. This would remove some of the need for optionals in languages that aren't able to dynamically create record types on the fly
- Implicit unions and union queries are really annoying to model in both OOP and FP languages. In FP disjoint tagged unions with no inheritance would work better; in OOP common interfaces but no ability to define unions would work better. As it stands, the mix makes it difficult on both language types to support a general schema. Unions based on optional fields (like in GRPC) are probably best-of-both-worlds here.
Re: GraphQL kinda sucks
#448Earlier quoted context omitted.
> 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…
no I'm just wrong, sorry!