I also refuse to use GraphQL (after seeing it fail utterly and spectacularly in a high-profile project that chose GraphQL because it was the "new shiny"). But I'm sure it has some niche that it works for. After all, people are still using it in 2022.
GraphQL kinda sucks
121–130 of 448 posts
Re: GraphQL kinda sucks
#122Earlier quoted context omitted.
If that field isn’t populated aren’t you in the exact same spot?
Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.
A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me.
Of course there are ways to prevent data from being returned but that’s fragile.
Re: GraphQL kinda sucks
#123Some other bad things: - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved i…
It shifts the complexity to the server side. The additional logic you are describing currently lives on the client, where it's harder to update and likely duplicative across platforms.
Re: GraphQL kinda sucks
#124Earlier quoted context omitted.
> It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Well, at least I'm glad I know I'll never be working with you! I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment. Whenever I see a comment from any developer that says "If yo…
You are right that this arrogant attitude is juvenile, but it is prevalent amongst humans in all areas. Unfortunately, there would be few developers to work with if you apply the policy of not working with arrogant, dogmatic developers.
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 contributors that the powers that be erroneously believe are irreplaceable.
Anyone can be a 10x developer when you sabotage the well-being and productivity of those around you.
Re: GraphQL kinda sucks
#125Graphql gets hyped by people who have seriously no idea what the hard problems in apis are. It quite literally solves many easy issues and pretends solve the hard ones, but does nothing to actually do this and just says that you "can". I designed a typical JSON api that had customizable fields and filters and joins and authorization on orm level on classes(could easily be extended to do authorization on fields of the…
I'm all for piggybacking off of Fielding's work, but HATEOS isn't practical and the industry reflects this.
Re: GraphQL kinda sucks
#126It's not an unpopular opinion: it's true. Graphql is a terrible piece of software/paradigm. I've completely avoided it for years. If a potential new job contacts me and they use graphql, it's an immediate no from me. It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Run away, as fast as possible.
> It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Well, at least I'm glad I know I'll never be working with you! I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment. Whenever I see a comment from any developer that says "If yo…
I felt pretty confident about my conclusions of my first dusty old bank job that used a custom shittier homebrew of google web toolkit and no source control.
Re: GraphQL kinda sucks
#127As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis - on graphql.org they say the best practice is to avoid breaking changes. [1] That said, versioning of a graphql api has been done at scale before. Shopify has done it, using versioning in the URL, specifically their admin data api, using month-year release dates as the versions [2] [1]: https://graphql.org/lear…
> As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis In reality, of course API versioning is needed. The "prevailing wisdom" is people who like the tool, don't like its limitations, and want to pretend it isn't a problem. . > That said, versioning of a graphql api has been done at scale before. Shopify has done it Perl people will happily point out that object s…
FB is pretty much on V1 of its GraphQL API with tens of thousands of engineers editing it for over a decade. Every single query is its own version, that's the point. If you want to change the semantics of a field, make a new field and leave the old one for the existing clients. What else would you have to version?
Re: GraphQL kinda sucks
#128Earlier quoted context omitted.
If that field isn’t populated aren’t you in the exact same spot?
Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.
Why not just query the database directly then?
Re: GraphQL kinda sucks
#129Earlier quoted context omitted.
Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.
A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me. Of course there are ways to prevent data from being returned but that’s fragile.
How does GraphQL help here?
Re: GraphQL kinda sucks
#130> It can save you bandwidth. Get what you ask for and no more On the other hand, you tend to do "select * from FOO" and get more data from the db, because you don't know what the caller will ask for. I don't think I've even seen a codebase filter the SQL based on the caller. I think I tried doing it once and it was a pita. (Please correct me if it's easy).
The typical approach that I've seen is to do "select * from FOO" for simple scalar fields that cost very little to retrieve from the database. If you have any fields that often contain large amounts of data, or any relations, you can provide a separate resolver for that field or relation, and then that resolver will only get invoked if the caller requested it. It's pretty straightforward, at least when using Apollo and TypeScript. (Obviously you would modify the original query to exclude such expensive fields so that you’re not duplicating work with the additional resolver.)
I still don't think I would personally recommend GraphQL to most companies.