I Am Done With Graph QL After 6 Years

[@AlexanderZeitler]

I am done with GraphQL after 9 years of not using it

[@BistaNadig]

Time to rm that decade old "try graphql" to-do note.

[@AvikNayak_]

Your profile image makes this comment even more funnier.

[@ZM-dm3jg]

One thing I've learned is that if i procrastinate on using the hot new thing for a couple years it always goes away 😂

[@AvikNayak_]

@@ZM-dm3jg I am also skipping on using nextjs let's see what happens

[@stoogel]

It’s great not being an early adopter in the web world.

[@overbyte]

Smart. It’s bullshit

[@science_trip]

hobbyists are done every 2 days untill they will find a job. after that they will follow the way that company requires

[@voskresenie-]

yeh, I've been 'over' aws for a decade. but guess who's still using aws: every employer I've had, and consequently, me.

[@jfftck]

The best feature of GraphQL, it can have circular references and this requires the developer to be aware of this issue and write something that would disallow it. Who would have thought that creating a service specification that is effectively giving API level functionality that is equivalent to SQL and that couldn’t be exploited? The first time I implemented a service with GraphQL, I was trying to figure out how to limit a query - which I don’t think many of the libraries had at the time - and this complexity makes the technology so difficult to manage and build that the time it takes to add a REST endpoint to accomplish the same task is so much shorter.

[@someman7]

As I understand (I don't actually use GraphQL), the whole point of is to be flexible. But I thought you're only flexible during development, and the API gets solidified for a given release. As for your (historic) anecdote about rate limits, figuring that out seems to be a one-time cost, while flexibility in development is a continuous benefit.

[@jfftck]

@@someman7 You have to protect yourself against circular references, massive data pulls, etc… It is a lot of effort to have that flexibility and, for me, it doesn’t make it worth the hassle. Additionally, since it’s more complex when compared with REST, you will have more chances for security bugs in whatever flavor of GraphQL you’re using. It just feels like a solution for a problem that I can solve in less than an hour using REST and, if you are using a language that has strict typing, it shouldn’t be that big of an issue maintaining type safety at least on the server side and you can fail all requests that don’t conform to the data contracts for each endpoint. But I understand that it is a larger issue if your server is running TypeScript/JavaScript, Python, Ruby, or any other programming language that doesn’t have strict data types. So, it’s fine if this works for some, but I think many will start a project with GraphQL with a feeling that it’s the greatest thing ever and then, months later, find it being a source of pain to maintain it.

[@JohnSmith-op7ls]

GraphQL is just another one of those poorly thought out things that got popular because so many devs love to crawl up into the butt cheeks of big tech companies and assume if they’re doing it, it must be the best, and also they’ll seem smart if they do it too.

[@JohnSmith-op7ls]

@@someman7Flexibility is always a trade off, it’s not free. If you don’t know for a fact that you need that level of flexibility, and it’s worth the cost, don’t do it. Way too many devs love to choose stack and design for hypothetical future requirements that 98% of the time never become needed, and they carry that technical baggage around for nothing.

[@someman7]

@@jfftck I was told (in a reply to a comment I made in the main thread) that "Most GraphQL systems literally do not allow nested queries. Like the system stops circular references and returns a null." With that in mind, I'm not sure why limiting would be harder than in REST. *shrugs*

[@user-ge2vc3rl1n]

Daily reminder to ignore hype trains: Old is boring, boring is good.

[@iraqinationalist7778]

What about phoenix vs laravel?

[@CottidaeSEA]

@@iraqinationalist7778 Spring.

[@iraqinationalist7778]

@chrishoppner150 don't know, php is hot sh;t rn

[@Ktulhoved]

This is not true. I can't find a better solution for managing micro services than the graphql federation.

[@Petrovich2049]

@Ktulhoved better solution is to not build microservices.

[@almicc]

Maybe I don't understand why anyone would use GraphQL in a public-facing interface, but it sounds no different than putting a button on your front door that instantly blows up the house, or a textbox on your website that runs SQL queries on your server.

[@catcatcatcatcatcatcatcatcatca]

I think it’s more like a powersocket next to your front door, but with no fuse . Given a correctly shaped piece of metal anyone can burn down your house. But if you or your neighbour you don’t mind borrowing a socket ever need more power than a normal house fuse can provide it is very convinient. There is little convinience in buttons that blow up your house.

[@mckidney1]

I think the confusion comes from the anyone, the problem is simple resource economy: Is it cheaper to make my house redundant or to make as many mailboxes as there letters. Article (imho correctly) adjusts the needle from some to almost nobody.

[@thewhitefalcon8539]

Usually they filter the allowed queries to be the exact ones they tested.

[@oggatog3698]

/api/v1 is an emotional support api prefix

[@devinjohnson5759]

Why do we have a prefix like this at my job too 🤣

[@nivethan-me]

​@@devinjohnson5759 for api versioning

[@aravindpallippara1577]

@@devinjohnson5759 Same here as well!

[@user-qr4jf4tv2x]

graphql are for people who front end and back end hate each other but friends with the middle guy

[@rauru8570]

In my company people use GraphQL to make bakend-to-backend integration, and it's been nice since the security part is less of an issue and it would eb harder to make teams stop what they're doing to create new endpoints. But yeah, it's the pattern of "new tech not so new anymore. People are finding out it's not the best for every case".

[@jly_dev]

I've been working on a GraphQL API for about 4 years. It's been nice. Our app is fairly large/complex, and a well-organized GraphQL API saved us from maintaining 1000+ dedicated REST endpoints.

[@zhoulingyu]

Your argument is flawed. What endpoints are to an rest API is what queries and mutations are to gql. They are just same shit in different toilets. Think again. Do you really have 1000 REST endpoints with 1000 entities or 1000 RPC endpoints with 1000 backing callbacks. Gql provides a structured way to subset fields and specify filters etc. Other than these, it is really not that different from REST.

[@jly_dev]

@@zhoulingyu lmao yeah no, try again 👍

[@Th3T1redPanda]

That statement is in my opinion not true. GraphQL is REST API with extra steps. You can have identical API, doing the same with the easiest and most common communication method. Queries just won't be so elegant. Needing 1000+ endpoints is a sign of not understanding what one is doing. I was able to build and maintain REST APIs for 20+ mobile apps all by myself. My solution: vanilla PHP (no composer, no autoload, direct lib include) + FatFree "framework", served by nginx/apache with URL -> php file mapping, with file per endpoint. You'll endup with an AWS Lambda like solution. Simple, clean, easy to maintain and scale solution. It will be exactly the same stuff, will just less. You haven't build such stuff before and started from graphql, do you?

[@jly_dev]

@@Th3T1redPanda lmao

[@5epo]

​@@jly_dev I swear this comment section is packed with people who have never used GraphQL uttering nonsense

[@ishamyyl]

prime's absolute refusal to attempt to understand ruby is hilarious

[@NostraDavid2]

Isn't Ruby pretty much a Functional Programming language, other than all those pesky Objects? Somewhat Lisp based, somewhat Smalltalk based. Makes sense Prime doesn't want to learn. It's too close to Haskell!

[@smoked-old-fashioned-hh7lo]

@@NostraDavid2 ruby has nothing to do with haskell or any fp language. it's a lot more similar to python and javascript. before node was around, everyone was using ruby and php. it's a very simple and easy language to learn.

[@stevenhe3462]

@@NostraDavid2 Ruby is an expression language and is nowhere functional-everything is mutable and effectful.

[@cbaesemanai]

I worked on a large project where we had graphql being called by event pipelines. We dos'd ourselves weekly with all sorts of cascading event triggers, it was a nightmare.

[@CKSLAFE]

nice

[@KevinJDildonik]

This is like saying allowing users to type "rm -rf" into a production database causes issues. Just use persisted queries. Tada.

[@SpikeTaunt]

Good thing I never learned it

[@swojnowski453]

I just waited till they came to the conclusion it was not it ;). It always happens sooner or later. Bleeding edge dancing is more fails than wins ...

[@KevinJDildonik]

I make 6 figures programming it. Feels good.

[@SpikeTaunt]

@@KevinJDildonik random flex on a random comment section,

[@swojnowski453]

@@KevinJDildonik 6 figs only feels good in places where there is no inflation

[@natescode]

​@@swojnowski453😂 unfortunately true. Six figures is poverty is San Francisco. "I make six figures" while also on food stamps.

[@popcorn245]

Trust and Safety mentioned, keep flaming that cloud.

[@rzr1191]

The attack surface problem is easy to avoid with persisted queries (assuming your API is only intended for known clients). End users aren't able to make arbitrary queries but frontend team get full flexibility

[@EikeSchwass]

Yeah I wonder why the author completely skipped over that

[@Ktulhoved]

Authorization is not a problem as well if you have necessary claims in token. Skill issues.

[@KevinJDildonik]

For anyone who doesn't get it: This is like saying allowing user input without sanitization causes problems. Duh. So all modern GraphQL systems (should) have persisted queries where these rules are harshly enforced.

[@dominikvonlavante6113]

But what is then the point in using GraphQL when you are only limited to persistent queries? Those I can build with REST. The entire point of GraphQL is to enable highly dynamic queries.

[@karakaaa3371]

@@dominikvonlavante6113 The point is persisted queries can be created by other engineers in your company, so you don't have to keep adding new REST endpoints because one team wants A and another wants B.

[@thatryanp]

Our CTO drank the Kool-Aid that our AWS product manager was mixing. He actually thought that graphql AppSync would be billed more cheaply than basic rest gateway. Our browser-callable public API was graphql. None of our customers could figure out how to get the websocket subscriptions working. We had to provide reference implementations. Any challenge to the graphql decision was dismissed with prejudice. Feels so good when marketing and sunk cost override clear thinking.

[@krtirtho]

Btw, GraphQL recently (maybe a year or 2) added *persisted query* support. It's basically storing a pre-defined set of GQL queries on the server. All these queries will have a unique signature that can be passed to a GraphQL client, which then will run the pre-defined query stored in the server without needing to write the query in the client. Whala, we're back to REST APIs with extra steps and massive request overheads

[@ZoranRavicTech]

It was not added, you always had the option to define queries on the server side. And it is still nothing like REST, even if you are using persisted queries.

[@PaulZyCZ]

Listening to this while working on higher-level GraphQL code, but we are leaving most issues on the provider of the framework. You don't touch stuff below gateways and subgraphs like the OP did, unless it's really your thing. It's like writing a web application in C.

[@someman7]

Isn't GraphQL supposed to be this flexible only in development, while in production it is restricted to what the official client actually ends up using, meaning that, unless the official client is making nested queries, you can't make nested queries as well?

[@KevinJDildonik]

Most GraphQL systems literally do not allow nested queries. Like the system stops circular references and returns a null.

[@old_gaffer]

This guy basically shot himself in the foot by admitting that for 8 years (2018 - 2024 / adoption - disilution) he never had requirement to write performant, secure or maintenable software. That's a real bad professional growth curve.

[@ZoranRavicTech]

And people eat it up anyway.

[@UNgineering]

Trust and Safety team mentioned. Upvote!

[@ChristophNolte-oh1wu]

I don‘t know about Ruby but the authorization in Go with GQLGEN is as simple as for REST. Normally you add authorization for a whole type and not for every field. But the difference is you can add it for every field in case you need it. Also the point with performance is constructed and not true in most of the cases. Open API is no comparison to a real typed endpoint that GraphQl offers you. TRPC is not an option for every Backend that doesn’t use Typescript and GRPC doesn’t run in the browser. Sorry but GraphQl is for many use cases still one of the best approaches.

[@stevenhe3462]

I thought GraphQL is for the backend not frontend. What are these people doing? Exposing arbitrary queries to their users?

[@outwithrealitytoo]

I understanc GraphQL being used directly by an SPA is a problematic - but as a method of data access between the backend web app and the DB surely it is a reasonable option. As a language and more flexible replacement for sqlc or grpc for example/ It would surely be better than an ORM?

[@LetterlessAlphabet]

Ok, that Cloudflare bit about DOS-ing yourself was funny.

[@tomtech1537]

Communism comment on point. When people say REST they just mean a GET or POST HTTP endpoint. Very rarely do they mean the full verb set (PUT, DELETE, PATCH, UPDATE,...). This ends up being a lot easier to manage with the various API/security layers that inevitably get baked into enterprise environments, and I'm ok with that, but be better if there was clearer nomenclature.

[@EikeSchwass]

We are currently implementing a reporting type thing that needs access to our legacy business logic and can't use SQL queries directly. It's pretty trivial to throw a GraphQL server on top of your existing API. We define our report data fetching as graphql queries, but only allow persisted queries to be run. Adding new reports is trivial and doesn't require changing any code, just insert some more queries into the database and everything works. Because it is build on top of our existing API, auth is solved automatically as well (with some caveats). Providing a general public graphql endpoint sounds difficult to get right, but there are use cases where it really is amazing and building that reporting thing right now is so much fun, because it feels so elegant.

[@ZoranRavicTech]

What's the advantage of using gql for your case? Can't your reporting thing access the api directly?

[@EikeSchwass]

@@ZoranRavicTech 1. The data is distributed over a lot of services and the node and edges concept of graphql helps a lot there. 2. N+1 on the client is impossible to solve for our legacy public API (in some cases) 3. Flexibility is really nice. We don't need to change our endpoint to allow newer reports. The more reports (and nodes there already are), the easier it gets to add new reports.

[@ZoranRavicTech]

@@EikeSchwass sounds like a great use case

[@tribes2archivist]

Squeal light is a cursed phrase. I really hate listening to it. If my colleagues start saying that, I'm switching jobs.

[@markdewey6788]

I've had a lot of success with graphql, but I'm coding in a walked garden where I can trust all the clients that are hitting my apis. Auth has been easy and left at the per-query level. So I haven't had to deal with the complexity described here.

[@ZoranRavicTech]

They talked about GraphQL like it's completely broken, but I don't think they realize many people wont ever run into those issues.

[@chambaderaphael8946]

Microservice graphql is the greatest thing that has happened in an enterprise context. Consistency, robustness, responsibility

[@mattymerr701]

This sounds like a programmers are human too quote

[@funkdefied1]

27:45 is such an awful take haha. Every boundary between two processes has an API. That boundary is what the “Interface” in API means. This API can be explicitly written or learned through tribal knowledge. I would much rather work with the team that documents their APIs.

[@gbroton]

14:35 that's why bff should be owned be the same team as ui. Of course, the bff still needs to get data from somewhere, but the same thing applies to graphql if that's the case. So owning bff+fe by the same team solves this issue, and no graphql is needed. Of course the development of be part will take some additional time, but velocity inside one team should be fast enough.

[@orterves]

Isn't there some way to take the set of graphql requests in the code and set them as prepared statements for production deployment? You'd get the flexibility in design and development of the front end, and effectively a standard json API out the other end

[@lobovutare]

So you mean, a frontend engineer writes the spec for they want to get from the backend and then a backend engineer can implement that spec? That's called OpenAPI.

[@orterves]

@lobovutare no, I mean the backend engineers implement a graphql service for development, the frontend develops and settles on the set of queries they need, then the build step locks in and optimises for just those queries - and doesn't allow others - when deployed to production

[@BfhChaosXX]

Authorizing fields works much better when you integrate this functionality with you database (e.g. RowLevelSecurity). While that also has to be maintained, you can't accidentally break it if you mess up in a handler somewhere :)

[@andreobarros]

I was done graphql in about 6 days. It was the time it took me to understand the basics of graphql, and to decipher this (somewhat big) project i just entered, that was graphql. Well, the project is basically already in production, so it is what it is.

[@josevargas686]

21:58 is implementing a little cache suddenly not a tool in any SWEs toolbag? it doesn't take a library to do in less than a day lol

[@rzr1191]

A piece of advice to anyone considering GraphQL - just use Relay and Relay spec... and if you feel like Relay is too complex for your use-case then perhaps consider ditching GraphQL altogether and going with a simpler approach like trpc or similar that still gives you type-safety.

[@dylan_the_wizard]

Oh another article about skill issues. Been using graphql in production on multiple apps from small to enterprise size, it's a joy to use once you wrap your head around how to properly do it. The article author is making a big deal over things that could be easily fixed, maybe the ruby framework he's using just sucks.

[@ZoranRavicTech]

Right. I'm tired of these guys writing about issues that they essentially created themselves.

[@Pretagonist]

Yeah I feel that unless you're writing your graphql stack from scratch the gql package should have mitigations for many of these issues. But you do have to be very careful about what you expose to your graphql endpoint.

[@matthias2586]

Thanks man. Saved me some time to write.

[@kasper_573]

In terms of suggesting replacements for graphql, this article completely glosses over the graph portion of graphql. If you have a large amount of services that you want to build a single coherent api facade for, openapi provides nothing for you in that area. You’ll have to roll your own service relationship mechanism.

[@celchronicles]

I mean that's basically an API Gateway plus a Facade.... Which is also what GraphQL framework does anyway

[@swojnowski453]

do not oversaturate your app with services, if you are a firefighter you are not a policeman, being everything means being a supermarket, but we all know what's wrong with supermarkets, they sell cheap crap ;)

[@kasper_573]

@@swojnowski453i would also recommend avoiding microservices and graphql for most projects. They are large scale concepts that will drastically overcomplicate things if you choose to implement them before you actually need them. But that doesn’t mean it’s never useful, or a deprecated approach. Our industry is plagued by people who fail to grasp nuance and only remember extremes, ie ”graphql good/bad”. Or people who start projects with a stack and architecture without truly knowing if their choices are appropriate for the project, and they’ve just chosen what’s popular. Sometimes microservices is the right choice. Sometimes you’ll need an api gateway. GraphQL could be benefitial here. Or . This is the nuance and exploration I’m missing in the article.

[@josevargas686]

@@kasper_573 yeah, people only care about 1 thing: am I using the BEST tool right now?

[@bradclements1815]

@@swojnowski453 wait, you forgot about "Fire Police" en.wikipedia.org/wiki/Fire_police Yeah, its a thing.

[@ericb7937]

6:20 and what stops doing this maliciously in REST with a loop?

[@popcorn245]

Nothing, necessarily, but the only difference is in GraphQL you have a schema, so you have a map of the whole API, which your restful endpoints won't have. My problem with graphql was less about security, but more about promise trees being slow and no built in caching so have to do a lot of work to make it performant.

[@mattymattffs]

Rest has pretty simple rate request limits and caching is much easier

[@AaronMartinColby]

I feel validated by this. I tried on three occasions to make GraphQL make sense vis-a-vis my standard REST patterns and could never make it work. REST always seemed better. I legit felt like I was missing something and had a skill issue.

[@ZoranRavicTech]

What kind of problems were you running into?

[@AaronMartinColby]

@@ZoranRavicTech Primarily optimization problems. We could never get our head around the exact way data was flowing like we could with a basic REST endpoint. We could never really understand how to best cache things. And every time we reached a point where we could actually benchmark something, the GraphQL request would be upwards of 10x as slow. Genuinely, we thought we were just too stupid to get it and would need to pay a lot of money for some classes or contractors to show us how it's done. The thing we really wanted was response shape validation, and we got that with JSONSchema and a TypeScript monorepo, so we just sort of dropped GQL. I shared this video with my old coworkers so they could also feel less bad about themselves.

[@jpatton3050]

The over-the-top reaction to a Ruby DSL at ~ 10:30 is definitely annoying to me. It's always a great time when someone reacts to something their seeing like "ahh gross" without even knowing what they're looking at.

[@nace.plesko]

Isn't response 200 "failed successfully" also a practice in htmx? Or is there any good way to get around it? 🤞

[@daltonyon]

Really great article, 6 yrs is a good amount of experience in a tool!

[@ThemisGaming]

With Apollo Router and their flavor of GraphQL you can do a thing called persisted queries which are known queries your client sends saved into a db of sorts. You can then block any unknown queries and only allow the persisted queries to be sent so only known queries can hit your end servers. This stops the whole taking a query, modifying it to request a billion data elements and sucking up CPU time

[@WhyWouldYouDrawThat]

Data and integration are my main thing, and have been for decades. The best way I can distill all of this is to say focus on information. Users of an apps don’t do much. Think about this. Incoming api requests (unique to 1 user) only have to capture what they are pressing. Hell, just send ONLY the press events if you want. Everyone wants to overbake everything. This is also true for enterprise integration. Everyone makes out it’s super complicated. But what are the users actually entering into their screen? Sync that, and structure it simply. Once you have this down, API design will follow naturally.

[@semyaza555]

Why not just use J’SON API to create an endpoint?

[@semyaza555]

21:57 Lmfao

[@justanothercomment416]

You clearly care more about correctness and robustness than the buzzword technology of the day. How dare you.

[@NostraDavid2]

I presume "J'SON" is pronounced "Jismal"?

[@attilazimler1614]

those non-functional requirements mentioned in the first 2 minutes are also known as "the production environment" :D

[@LinhLinhBD]

remember folks, facebook gave us react and graphQL, thanks for wasting a big chunk of life writing react and redux boilerplate. I never used graphQL, it never sounds good to me from the beginning. The react and redux hype train were impossible to avoid in the 2015s years.

[@VV-nw4cz]

At some point an "I know it all" contracting firm came to our company and said that they would replace a process that had ETLs with SFTP and pipe delimited asci files transferring millions of records with GraphQL... I was extremely skeptical, if not to say more... few million dollars later the project ended up being scrapped. GraphQL is a great tool for a few very specific use cases. It is not a general solution by any stretch.

[@kevinmccarthy1196]

REST works well for application-defined data types (which suffices for 99% of apps). I use GraqhQL for user-defined data types (extensible schema) and ad hoc queries (reporting, etc). It does pretty well there but still is far from perfect. Paging is terrible/unspecified, and can be impossible for multi-root queries (ex: list all Xs, Ys, and Zs in the same query, where each record type exceeds the page limit). It does have some usefulness to eliminate the number of calls needed for UIs to do joins, but still think doing custom backends that are efficient and fast are worth the trouble 99% of the time. Back-end work is light speed compared to tweaking UIs.

[@martytheman6816]

Suitable alternative for use with F# ?

[@T1Oracle]

If your app needs lots of custom queering functionality driven by unpredictable user requests, then use Graph QL. If your app tends to do the same exact queries every time, just use REST. I've known this since the start.

[@natescode]

Exactly

[@ZoranRavicTech]

But then you lose out on request batching.

[@thewhitefalcon8539]

Oh there's lots of custom queering in this gay as heck app

[@TurtleKwitty]

GraphQL is the exact same thing as firebase/supabase. But good luck finding a GraphQL aficionado that wasn't extremely anti BaaS

[@tonyb3123]

GraphQL is a good query language with some weird warts and idiosyncracies. 1. People are using it in places they really shouldn't be 2. The most popular implementation is Apollo and Apollo is hot garbage

[@hardcorecode]

graphql-request.... it's so simple I don't know why it's not more popular

[@josevargas686]

did no one tell them that GQL works only for highly relational data?

[@ZoranRavicTech]

You don't even need apollo. Idk why is it even popular, considering how little it adds.

[@xixixao]

That first footnote is crucial. FB did not use GraphQL for external APIs, only for its own clients. So this is what the author should have used and would have solved almost all their problems. Shame Prime didn’t get into it.

[@ninocraft1]

graphql was such a headache

[@erikslorenz]

GraphQL was the first hype train I ever got on, then once I was using it I was like....why did I do this? Then other junk like Gatsby started using it for no good reason and I steered clear.

[@TheBadFred]

What about SOAP, is this still used - just smooth XML? There is also gRPC, which is more flexible than REST.

[@lobovutare]

SOAP? That's not hip! We need REST. REST? That not hip we need GraphQL! GraphQL that's a shit show, we need REST with a spec! REST with a spec? How's that not SOAP?

[@karakaaa3371]

XML is cringe

[@TheBadFred]

@@karakaaa3371 It's an Extensible Markup Language.

[@ConernicusRex]

At Facebook where they invented it they were over it in like 2 years. What took dude so long?

[@semyaza555]

It’s easier to cut bait when you’ve seen how the sausage is made.

[@ColinFox]

@@semyaza555 I do not think that expression (cut bait) means what you think it means. :)

[@juliancorredor1128]

Any source? not to doubt you but I would like to read more about that

[@armaandhanji2112]

It's okay to dislike a technology, but let's not spread false information. Meta hasn't abandoned graphql at all lol, they still heavily use Relay in critical infrastructure.

[@ConernicusRex]

@@armaandhanji2112 talking about forward facing APIs not private relay where it’s as you mentioned still used in at least half of their service layer.

[@ayesa1118]

I have only worked with 1 GraphQL endpoint and it only had 1 client who used the exact same query every time

[@vladimir5935]

Supabase solves this. Postgres extensions can expose both rest and graphql APIs for your database and you can restrict access with row level security. This is quite powerful because for small applications you can remove the “backend” completely and make the database your backend. You can make triggers and have them call into whatever is left of your backend code or make HTTP requests from your database functions. And hopefully all of this without turning your app into a security sh*thole

[@jfftck]

This is great if your data is only from a DB and doesn’t require external services. My team is building integrations with multiple services and we can’t keep the data in DBs because that would change the source of truth for the data.

[@vladimir5935]

@@jfftck yeah that wouldn't work very well. in my case I just call into openai's APIs from a serverless function and all the data is in the db. do you use graphql for your use case? sounds like it could work for you

[@kahnfatman]

GraphQL would be nice if it were compiled into native SQL and executed on db side, rather than composing a bunch of Resolvers, which execute statements separately. Imagine a SELECT statement that return 20 items and each of them fetches the details over 20 individual SQL statements. 25:34 did he just say: Edge titty pee?

[@NostraDavid2]

"Aitch titty pee"

[@ZoranRavicTech]

I think Hasura can auto-generate GraphQL for your db. But you also need to have business logic, so I think you still have to write resolvers somewhere.

[@Neunzahn]

GraphQL is not only about some SQL queries, the source of data could be also a different server or anything.

[@framegrace1]

The first I noticed when learnt about graphql was the http code and http action thing. If everything is GET and everything is 200, a lot of very usefull middle ware (LB Routing, Caching, etc...) will stop working.

[@komfyrion]

Small correction; with GraphQL everything is POST.

[@ZoranRavicTech]

You can still have caching with GraphQL. But you need a library that correctly handles different requests.

[@ZoranRavicTech]

@@komfyrion Nothing about gql requires you do use POST for everything. The correct method should be GET for queries and POST for mutations. Some libraries only use POST, but that is a limitation of those specific libraries and not anything to do with gql itself.

[@komfyrion]

@@ZoranRavicTech Right, my bad. That's an Apollo Server implementation detail.

[@framegrace1]

@@ZoranRavicTech Yeah, some engines had to create a workaround, by (basically) turning specific queries to REST gets. THe problem keeps being the same, is not prepared for the REST world.

[@Mempler]

I've never seen a reason to use graphql. Thus, i never used it. Rest and gRPC is always easier to use

[@ZoranRavicTech]

Can you batch your REST api requests?

[@iqbali4u]

Why did the GraphQL server send a 200 response code for an error? Because it wanted to say, "I'm successfully letting you know I messed up!"

[@svorskemattias]

Sometimes you stumble upon a video and you must check how long it is before you start to watch because it is possibly half an hour rambling and screaming. Even though the topic is interesting, and you're like dude I can't listen to all of this, I just can't, I need you to like, like, bring it in. A little bit.

[@Direkin]

I have a GraphQL project on the backburner for a while, and then I started seeing all sorts of articles about its vulnerabilities.

[@ZoranRavicTech]

The issues they mentioned can easily be avoided, at least by devs who have had experience with gql.

[@robbiedozier2840]

so i'm a bit confused because it seems like most of these problems could be solved by some preprocessing of the query. they mentioned this idea of keeping track of query "complexity" not being an adequate solution but i don't understand why it wouldn't be: you know every data type's number of attributes and the size of each attribute, which could allow you to pretty accurately predict the size of the server response similarly, couldn't you have a greedy algorithm approach with auth so that for each query, instead of authorizing every single object, just figure out the max authentication needed and verify the client has that?

[@ZoranRavicTech]

That wont mean much for junior devs. If it is not working that way out of the box it may as well be impossible. That's why you see them talking about those all issues that could have been avoided.

[@creativecraving]

The way I understood it is that estimating the query complexity is easy to get wrong unless you have the skill to rewrite graphql; so it's far more difficult than just making REST endpoints the normal way.

[@ZoranRavicTech]

@@creativecraving You can skip complexity estimation and instead do the same thing you would do in rest and set a limit on the number of items in a response of a resolver + don't make it possible recursively call resolvers. Also if it is possible to write a rest endpoint then do that. Gql is best for larger or more complex api-s.

[@MortenBendiksen]

Graphql is basically coding the backend in the fronten. Good idea, but bad implementation. Instead, each query in the frontend should be injected at build time into some list of approved queries for the backend, along with user role requirements to run it, and have the backend verify on each query. Same advantages, but less problems.

[@battarro]

why do you pronounce it graph queel ?

[@Interpause]

im guessing it makes sense to still use graphQL between microservices on the same security level in the backend, just anything that faces the public should be REST for safety

[@Th3T1redPanda]

"Communism proudly and bravely solves problems unseen anywhere else, which it created itself." That's graphql is doing. People in US should experience some communism. To see how stupid it was, to be able to recognize this stupidity in other stuff. Also to discover that they're living in a Gulag and not in a civilized country. --- Soviet Union at it's end had more humane work law than US ever had. Go live in Poland for a bit to experience an obligatory 40h work week with a max 5days/workweek , 8h/day with a break time included. Being overworked is messing with thinking. To see how much, you have to see it yourselves. It might explain why people jump onto stuff promising less work without thinking.

[@comboschtap]

Maybe I am wrong, but is comparing GraphQL and REST not like comparing apples and lemons? :) Especially when implemented with Apollo Server - which he does not seem to mention at all in the video. Is it not true that both GraphQL and REST can encounter the N+1 problem if data fetching is not implemented thoughtfully? Is it not true that GraphQL just requires a different approach (like batching and caching with data loaders) to prevent N+1 issues in complex, nested queries, but these are solvable challenges? Also, is it not true that GraphQL doesn’t “have” the N+1 problem any more than REST does? Just asking. In other words I think it’s a matter of how data fetching is managed in any API. That is my understanding at least.

[@justanaveragebalkan]

Back in the days we used to call this sql injections, now people just call it a feature and put a price tag on it. What has the world come to.

[@Neunzahn]

You clearly did not work with graphql.

[@yayinternets]

Eh, a post from someone who primarily works in Ruby and TS. Skipping this one.

[@whitehat4u]

It's now the core in AWS services, I guess going to be like a life long for it.

[@anarchymatt]

Status code 200 Graphql error

[@meltygear5955]

It's insane how non functional requirements aka. "just mole hills" are so rare in my job market, I'm gonna turn into alcoholic

[@blipojones2114]

6 years!?....i was done after 6 minutes

[@Hannibal31-tx5is]

Bro stop making the titles/thumbnails look like it's about you. You're literally just taking someone else's opinion and selling it as clickbait.

[@ZoranRavicTech]

It wouldn't be clickbait if it didn't get both of us to watch the vid.

[@EricWilliamsCG]

Error 200: Task failed, successfully. Lol

[@dzisonline]

I like GQL. This probably isn’t an issue if you’re using SSR.

[@minhquando100]

If you’re going to be doing server side rendering, then you might as well not even bother with graphql and just use htmx.

[@Muskar2]

What's actually needed in a network API? A compressed byte stream, often consisting of a diff of changes. And end users should never control servers. If you're in a heavy red tape org, I don't know what else to advise other than make execs know what the red tape actually costs, or change jobs.

[@ZoranRavicTech]

In gql queries the end users control the servers as much as they do with rest requests.

[@ricmorris9758]

"I need infrastructure??? But I want to just run a report on your server to do my integration"

[@ZoranRavicTech]

@@ricmorris9758 with graphql you don't need any infrastructure to load data for your report, all you need is a single GET request. It's actually much simpler than having a flood of GET requests you would need if you used rest api.

[@Muskar2]

@@ricmorris9758 The best part is no part! And for necessary APIs, I want to do 'Designing and Evaluating Reusable Components'

[@happykill123]

*Cries in corporate Microsoft GraphQL interface*

[@filobonda]

I still don't know what graphql is

[@RevNelson]

Dude, the highlighting from the second-to-last to the second character in a sentence/paragraph is like nails on a chalkboard. At first I was impressed how consistently he missed the first and last character so often. Now I see it's really just that odd lisp you don't want to call out in your buddy but can't stand to hear.

[@jaskij]

I noticed someone posting the ferret butt emoji. Thor recently got it taken down for "sexual content".

[@dwylhq874]

GraphQL is 100% Emperor’s New Clothes. People don’t question it because they don’t want to _appear_ “stupid” among all the “smart” engineers. Slow, unmaintainable security nightmare!

[@universalequalrights8386]

GraphQL is awesome but needs some fixing for security and performance. They could implement an all-or-nothing query rule, along with a creep detector (like one try every 8 hours if the all-or-nothing rule is broken and not just by the same user but by all queries to the data triggering the rule). If even one slice of data is out of your security level, your query is immediately rejected as non-compliant. Then, if you aren't some hack bozo, you'll need to call someone in services that can help you.

[@deadchannel8431]

I get the points, but if my company were to use rest instead of gql for data fetching, out development would be so much slower

[@fluffow2675]

Soap only

[@popcorn245]

Who hurt you...

[@martinzihlmann822]

my eye itches when i remember reading xmlspec and: PUT 200 ok, authentication required.

[@hobbyxplorer]

i think working on front end in general has become a joke. if its not a server side rendered app/company i wont even bother.

[@motbus3]

Graphql is nuts. It does lots of implicit stuff and it is hard to configure properly and hard to maintain. It is hard to master and that's all red flags

[@josevargas686]

The whole issue is that people thought GQL was a replacement for REST, as if they were two hammers of different brands. GQL is a different tool than REST, one is a hammer and another is a spade, you can hammer a nail with a spade... but maybe don't?

[@PetarVukmanovic]

You, sir, have gotten a like from me on 9th min when you CloudFlared. Yes.

[@victor95pc]

Summarizing video: Pure skill issue with GraphQL

[@hardcorecode]

Yes, especially the part about authorization... maybe it's the ruby framework. I work with with springboot and it's so simple to implement!

[@Monsieur_Anderson]

@@hardcorecode yes, so simple that you have to wait 1 year to upgrade spring boot 2 to spring boot 3 for graphql compatibility because no one use this hyped sh*t anymore

[@hardcorecode]

@@Monsieur_Anderson I don't know what you are rumbling about. but basic spring security is straight foward to implement... oh I am still on JAVA 11 so I don't follow no hype train. I pick my tech stack very carefully!

[@Monsieur_Anderson]

@@hardcorecode Well, if you use GraphQL you are actualy in the hype train. if you upgrade your spring boot app, you are not in a hype train, you just fix critical security issues

[@victor95pc]

@@hardcorecode Dude probably pays for authorization service lol, everything is SaaS now

I mean you should not be using graphql on the client side

[@ZoranRavicTech]

I'm pretty sure that gql is primarily consumed from the client side of websites and apps.

[@ColinFox]

Easy solution. Don't use APIs like this, instead just build your UI in HTMX and do all the tricky stuff on the server side.

[@josevargas686]

you could even add GQL on the server side if you really need it, now you can add "friends" field without affecting anyone, without duplicating endpoints, and without updating documentation. People will want to be friends with you now!

[@ZoranRavicTech]

As soon as you run into a case where the UI has to be constantly re-rendered you will realize SSR is not an option and writing any kind of non-trivial logic in htmx is next to impossible.

[@nazarm6215]

kzbin.info/www/bejne/jnO4pIWMmtV5Y5o Pretty confident query hashes can mitigate all these DOS issues. The problem is additional complexity working on it.