Why I Don’t Use GraphQL Anymore

[@hswolff]

If you have an interest in discussing this in more real time, then join my Discord server! discord.com/invite/6YbKq8R

[@__hz__6983]

I've only used GraphQL with AWS Amplify. It generates a lot of stuff that serves my current goals, but otherwise I don't think I'd use it. Rest may be more primitive but simplicity is more valuable to me nowdays.

[@rickvian]

I have solution to all of this problem, introducing... REST API

[@kalahaval]

I'm totally on your side. The company I'm working for is using GraphQL and I still don't get the benefits for this project. I do see advantages for various use cases, but I think often it's just overhead. Especially in a small team. And often I'm unsure if the way it's implemented (in our app) is really the right way of doing it. And that feeling leads to my opinion, that it could be better replaced with classic REST or other (simpler) abstractions.

[@tommylemon4462]

Tencent/APIJSON is much better than GraphQL, especially on functions, safty and performance. And APIJSON is very easy to use because you don't need to write any code for API development. github.com/Tencent/APIJSON/blob/master/README-English.md

[@sumitkachare6628]

Even I am having the same situation as you . We have a project using graphQL but there is a REST server between frontend and graphQL server . I mean whats even the purpose of graphQL if its not doing whats its meant for in my project.

[@marcusrehn6915]

Have a similar issue where I work. I think the only benefit we get is that the schema is better than Open API. Also, if i need a mixed bag of values from different resources and it's better to do that in the backend, then I'll do that in the backend, Rest standards be damned. Although I might name it differently.

[@qodesmith520]

I work at FB, and let me tell you I struggle with Relay's complexity all the time! Not intuitive at all. Glad to see I'm not alone :) Great video! Keep these coming.

[@hswolff]

Great comment! Interesting to hear! And yes, I shall! Thank you!

[@aberba]

Relay looks very over-engineered

[@tommylemon4462]

Excuse me, would you like to share us how is the situation of GraphQL in Facebook now?

[@qodesmith520]

@@tommylemon4462 not sure exactly what you mean, but at Facebook we use GraphQL extensively. It's not going away any time soon.

[@tommylemon4462]

@@qodesmith520 thank you~

[@Martin_Adams]

Ahh dang, when Harry says GraphQL is out, you know you better pay attention 😂 I agree, GraphQL has a lot of complexity, but I've found it better than rest in the project I've been working on. It makes extending the application easier by knowing you have a strongly typed API schema. I've successfully implemented custom scalars, subscriptions for read-time updates, etc. I agree, it's very hard work to get there. My bugbears with GraphQL is inheritance and how it handles two child types using the same name property with different data types. And input types should support inheritance so you can pass in one generic object of different structures. They say there's a limitation because you don't know what type to expect, but it would be easy enough for the client to hint it in the __typename property. GraphQL is to Rest, what Kubernetes is to Virtual Machines. It doesn't make things easier, it just makes the impossible things now possible.

[@hswolff]

Great comment Martin! Always a delight seeing your input! Thank you!

[@maurovalvano5707]

We are using relay + graphql with the new backoffice of our software and we made a huge improvements with relay. No more repositories or manual ajax calls, no more defining endpoints, automatic component dependiances, Intellisense, type checks, auomatic query caches.... We got troubles too in some scenarios (e.g with a search bar in a parent component that will trigger two fetch the first time because we use the useEffect in the child to update the search results). But hey, 1 cons vs 100 pro.

[@maurovalvano5707]

@R S if you keep it too simple then you will have tons of boiler code, you also need something that help you on this. Most simple is not always the best.

[@asfallion]

@@maurovalvano5707 How big is the project? For myself I found that GraphQL was going super well and super at the start. The problems came later as the queries expanded and we had to deal with async loads, subscriptions which are still not first class citizens. @defer is still not mature.

[@maurovalvano5707]

@@asfallion our project is pretty big, but the graphql-relay is new but we already did pretty complex things. Nested fragments, etc... I will check what you you say about defers etc. Please note that we are using relay as framework that helps us a-lot.

[@staenker1983]

Omg, that’s honest and you even mentioned that not everyone is Facebook or Netflix. Keep up that kinda work, I’m happily waiting for another gem like that one :)

[@hswolff]

Thank you for the kind comment!!

[@TechdubberStudios]

I am in the same position as you are regarding GraphQL, only I gave up on it a lot quicker. I tend to pick technologies that only make my job easier, not the other way around. Hence, I don't use TypeScript, Graphql, React. I will stick with Sapper/Svelte and Rest until something new, that makes me more productive and doesn't give me more things to worry about/ more "chores" shows up. In other words, makes me more productive than I currently am. It may be just me, but it feels like some of these technologies were created by some corporate employees whom are paid per time spent writing code, rather than productivity. I don't wanna be writing code for the sake of writing code. I wanna do things as fast as possible, both on time spent developing and application runtime.

[@hswolff]

I love some of the sentiments you shared! I agree that tech should ideally work for you and not the other way around. I will say that if you get past the onboarding of GraphQL then it can be super productive, but it can be a fairly steep climb. Also Sapper/Svelte rocks!

[@cintron3d]

I haven't tried enough other frameworks to comment on react - I just personally love it. TypeScript however, while there is a little bit of a learning curve (less so if you already know C# since they are very similar in syntax) it absolutely makes me more productive. I can refactor code with more confidence, I can catch simple spelling mistakes as I write them instead of waiting to test in the browser and wondering why things are breaking. After switching to TypeScript, going back to vanilla JS feels like walking blindfolded in a thick jungle. I see junior developers getting hung up on the simplest things (misspellings, bad casing, missing arguments, wrong argument order/type) all because they don't have the IntelliSense or compile errors warning them. Then they spin their wheels trying to figure out what's wrong. Every time that happens I think inside - if only they were using TS we wouldn't be wasting time on these issues.

[@TechdubberStudios]

@@cintron3d your comment makes me re-consider my views on TypeScript. Thanks! I have worked with .NET C# on the back-end for a while, and I quite enjoyed. But I wouldn't pick it over NodeJS, personally.

[@TechdubberStudios]

@Christian Lewis Over-engineering is a curse, and TypeScript is over-engineered. That's my opinion. And yes, I completely agree with what you've stated.

[@luisarias272]

I have the feeling that you are not using the real developer tools for graphql, you can even combine a rest server with a graphql schema 😒

[@Khari99]

As someone who is currently building applications with GraphQL, I can definitely sympathize with a lot of what you're saying. I would say REST is more suited for small scale applications while GraphQL is suited for much bigger ones. What matters is using something that allows you to get the job done efficiently. When it comes to learning, I say something is only worth learning if it solves your problems efficiently. If it does then I recommend being prepared to learn a lot of new material. If it doesn't then use something simpler. There'll definitely a learning curve to GraphQL. You have to determine if you are moving enough data for it to be worth it.

[@fateriddle14]

Thank you, strong opinions are what I look for when deciding whether to use something :D I may not agree with you, but it's much more informative than those generic "pros & cons" type of video. Thanks for the great work.

[@h0ph1p13]

You agreeing or not does not count as experience. This guy has some experience ;)

[@fateriddle14]

@@h0ph1p13 Do you just randomly say some shit in a random video? Please go on, I'm listening.

[@cksmith007]

I’ve been an app developer for over 25 years and my absolute overriding principle is KISS. Occasionally you encounter complex problems that require complex solutions but those are rare in my experience

[@fuseteam]

well i suppose making one end simpler makes the other end more complex

[@_ericelliott]

I love GraphQL for large, complex data models. It's amazing for Blockchain queries and enterprise software. Overkill for most small apps.

[@hswolff]

I agree! Thanks for joining the comment party Eric! 😀

[@MDABDULMOMINRiyadh]

I'm confused in between conversation 😂

[@derEarl]

Thanks for your video! After years of successfully using REST I felt the pressure (from my younger colleges) of moving on to GraphQL :). So I started to get into it. I liked very what I learned see the benefits. But I felt that the two most weighted selling points of GraphQL doesn't pay out in my specific environment. Your video helped my to underline my opinion on that. So for know I looks like I will stop looking into graphql (for now) as It doesn't match my requirements despite of feeling more modern ;)

[@RedOchsenbein]

Yeah, got the added complexity stuff. However it does not make you use everything, and depending on the scope of the project you probably should focus on the core of what you really need. I found this to be the best way to tackle GraphQL and so far it worked pretty well. I guess the biggest pitfall to look out for is really the n+1 problem. But the concept of dataloaders actually deals quite nicely with that.

[@mearaftadewos8508]

The same here, bro. We are not dating GraphQL that we need everything to be perfect. And no framework is perfect anyway. So why not use the part that's great and you need then fill the other part with other frameworks or tools. And move on with your life.

[@chinyun1526]

I totally agree as a fullstack dev. There is not only a lot to learn, but also easier to miss some important things to implement. It's really hard to take care of: error handling, cache, query optimization with db(mongo especially), authorization. All the stuff are different big topic, and need to watch and implement carefully. I will never use graphql in my project next time unless easy and no-authorization project.

[@wolfymaster]

Been using GraphQL the last 4 years. I went through all those same frustrations. Tried Relay for a little bit, but fell back to apollo.

[@tommylemon4462]

Tencent/APIJSON is much better than GraphQL, especially on functions, safty and performance. And APIJSON is very easy to use because you don't need to write any code for API development. github.com/Tencent/APIJSON/blob/master/README-English.md

[@alexisdvt]

I'm with you, I think part of the job of a senior dev is to choose what tool does the job in an easy and fastest way, and sometimes the old but reliable tech is the solution that's why PHP and others are in the business.

[@hswolff]

Very true!

[@fdg6935]

@@smthngsmthngsmthngdarkside true

[@s1nistr433]

Virgin: You need to know React, Graphql, Node, Jabbascript and a million frameworks to be a good web dev Gigachad: Use PHP and a little bit of jquery

[@Developerish]

I explored GraphQL in its early days, and it’s pretty remarkable to see the progress and adoption it’s made. My personal philosophy has always been to be technology agnostic, and use the tools best fitted for the job. The magic of its resolving nature is like you mentioned, it’s strongest strength. When you have an application with data that have complex relationships, most likely you’ll benefit from GraphQL. In my case, I was using it to interact with data centers, which have complex topologies that can change at any given state, was incredibly challenging with custom logic. If the overhead is too much, it’s a good time to re-asses why it’s being used in the first place, and if new or bespoke solutions are better suited. Reminds me of the Redux hype for several years, that was fun in React circles for a long time 😂.

[@daniellionel01]

The n+1 problem is solved by most popular graphql frameworks / libaries and people are very aware of it.

[@remedygrime]

e.g. dataloader

[@ЗахариПалазов]

I am using Apollo federation with microservices in my workplace and till now we are able to implement composition of data with N async requests, it is not free lunch to learn it on the other hand

[@alanhoff89]

Yup, we just use dataloaders

[@dstudio1011]

I'm looking forward to using GraphQL -- but after a couple of hours just doing the tutorials found online (did not finished - head aches) I tried to read more how useful GraphQL is out there when I came across a couple of vlogs that 'hates' GraphQL. I decided to watch one - (this one) I begin to understand something about GraphQL, and put GraphQL into perspective. Doing full stack alone means projects are not that complex (I guess) so I'm not moving into GraphQL for now and REST it is. Thank you for this vlog - it's presented so that a 5 yo can understand. Also the comments helps a lot.

[@swyxTV]

Great vid! I would've mentioned dataloader and persisted queries for pple who want to learn more. there's also gqless which addresses the double declaration problem. I feel like you have been moving for forever!

[@hswolff]

Bahahah. Moved June, gonna move again next year when we (hopefully) buy a house

[@swyxTV]

@@hswolff exciting! the american dream. hope to visit someday!

[@ZiPMo85]

whoa! netlify guy appears!!! woohoo

[@swyxTV]

@@ZiPMo85 haha I left in March. aws guy now

[@marcusorelius8090]

I personally feel that each technical solution has its pros and cons and as a technologist our job is to choose least worst solution. There are use cases where graphql would be good but there are times it may not be optimal solution. We can go for hybrid situation based on the problem domain, use rest api where it make sense and grapqhl for situation where it is optimal. There is no one size which fits all, BTW great video. Thanks

[@amirnoorani5017]

amazing topic which is not discussed anywhere but I was looking for

[@djordjenikolic6560]

Agree 100%. I think biggest weakness is DataLoader and optimizing dynamic fields. It's like ur hacking.. almost impossible to run it fast, because you need those DB calls... But they say it's a strength, cause u easily return data.. u get hyped, but in background that graph is a way heavier than it should. I honestly think web grpc is the next step.. Also typed, but faster

[@tommylemon4462]

Tencent/APIJSON is much better than GraphQL, especially on functions, safty and performance. And APIJSON is very easy to use because you don't need to write any code for API development. github.com/Tencent/APIJSON/blob/master/README-English.md It supports APP JOIN which likes another kind of DataLoader while coding free. SQL Joins were provided as well, such as LEFT JOIN, RIGHT JOIN, INNER JOIN and so on. github.com/Tencent/APIJSON/blob/master/Document-English.md#2-keyswords-in-url-parameters

[@alanhoff89]

@@tommylemon4462 too bad I don't touch Chinese software

[@eugenpaval]

N+1 problem appears only because developers do not put the effort to implement a GraphQL server without it. It is definitely possible as demonstrated in Hasura and Postgraphile.

[@ThisOneGoes211]

Fragments are hard to use? What?

[@paulholsters7932]

Good video. I use graphQL for the first time now for the node framework I am building. So far it seems like I’ve made the right choice.

[@henrikholst7490]

I liked the format! Please make a video in this format on more technology. Kubernetes which is very hyped would be one obvious one fitting the same kind of rant, and the boxes fit right in for a container orchestration metaphor. 😉

[@silver12151]

Docker... another video where you can use boxes as a metaphore. And thanks nice video and information.

[@Ninja-qk5gf]

I love that you mentioned these tools have a problem they solve for Facebook...but "do I have those problems??". Nice.

[@mage1over137]

So I think a better way to put it is graphql is probably the best solution to all your problems, but you have to set it up properly and there are a lot of knobs, and certain edge cases causes issues. But if you do it right, you'll minimize your tech debt, on the other hand if you do it wrong you'll have rewrite at some point and do it "right" this time (I highly recommend do this sooner rather than later). It's like digging a hole, most holes you need to dig, a shovel is fine. On the other hand sometimes you need to replace a septic tank, which I would recommend a backhoe but only operate if you're properly trained to. (Though I suppose a test drive to get feel won't hurt.)

[@michaelslattery3050]

I'm using Hasura which I *think* mitigates many of these server-side issues, although you must buy into its way of mapping data.

[@shane3744]

Great perspective, many of your concerns are active problems which will hopefully continue to be addressed and improved upon. In regards to complexity, specifically with how GraphQL does error handling, I totally agree with your points. It's one of the main issues client devs have that consume the GraphQL server we build/maintain at work. There's some interesting ideas developing in the space around better error handling (Sasha Solomon has some really interesting ideas she developed as an engineer at Medium, check it out if interested), but they of course just add further complexity and learning what isn't inherent to the spec. Custom directives are... yeah, still nascent. Really interesting and have the promise to allow so much flexibility when interacting with a data graph. But they're just too unwieldy to build with today's libraries and most that I've seen only offer limited "cosmetic" functionality in queries (@deprecated, @formatDate, etc.). N+1 problem is mostly handled with DataLoader on GraphQL servers which functions as a pre-request cache/batcher. We (and many others) also implement query depth limiting, where we artificially limit the nested depth of a given query to mitigate the issue of excessively large queries. This problem is largely solved, but I think you're right that it is just another step to learn and the spec could be more opinionated on it. One of the biggest benefits of GraphQL for us has been the ability to act as an API gateway for our client apps. As we moved from a monolithic REST API to a microservice architecture, having a GraphQL API sit between our client apps and the backend has made the shift so much more seamless. While REST addresses and the data they serve change, the data graph remains the same and the client devs don't need to care about where the data is coming from, so long as the data contract is respected. This, along with client-driven queries and a statically typed data graph that you mentioned, is where the technology truly shines.

[@fateriddle14]

Can you talk a bit more specific about error handling complexity? I'm about to jump on this train, and only have a general idea of the frontend part, we are planning to build the graphQL layer with serverless functions using nodejs btw. I really want know more before fully commit to it.

[@shane3744]

@@fateriddle14 Sure, so in my experience, the main complaint with GraphQL error handling is that a response doesn't utilize status codes (all responses are 200 responses, regardless of whether they contain errors). For our client devs, it was a difficult shift to not just receive a a status code communicating the problem and, instead, traverse through an array of errors as is the convention in a GraphQL response. Speaking personally, I enjoy error handling in GraphQL and I don't really find http status codes to add much more value than a simple, readable error message could give me. But the main point is that the http ecosystem is built around the use of REST APIs without some of the conventions of GraphQL in mind. This forces developers who may not necessarily care if their data comes from REST or GraphQL to understand how the different methodologies handle errors from the API. I don't want to make it sound like GraphQL doesn't have a fleshed out error handling mechanism. It certainly does and I believe is even more flexible than what can be achieved when adhering to a status code system. If you're willing to put in the time to learn a bit about error handling with GraphQL, it will definitely meet your needs. Just keep in mind that if you have a large technology department and API consumers have a lot on their plate, a switch to GraphQL will add something new to contend with to their domain.

[@eugenpaval]

I implemented directives allowing query persistence on the server side. Then a client uses an identifier and a set of parameters to execute the query. Query now is shorter and faster to execute since it is persisted in a compiled form.

[@eugenpaval]

@@shane3744 A middle ware can actually set the http status code to the expected values. It s not in the specification that error conditions need be sent via 200.

[@Kim-by5uy]

I think apollo server has adressed a lot of these problems

[@gfinzer]

I see a lot of developers chasing shiny things which usually correlate to more complexity. In a way we are creating job security since it takes an inordinate amount of time to maintain the codebase. How I wish we would adhere to the KISS principle.

[@freemind108]

Well Great Info, Exactly what i was thinking of it from server point of view. considering the n+1 problem i better rest with REST and don't want to bring so much of Heat to QraphQL server, as i don't know much about qraphQL advanced part.

[@usmanmughal5916]

Yea just stick with REST.

[@shamim083]

Excellent video Harry.

[@nfh3]

JSON:API solves the catchability issue, while retaining the ability to specify partial objects, dependants etc

[@tommylemon4462]

Not JSONAPI, it's APIJSON, lol. github.com/Tencent/APIJSON/blob/master/README-English.md

[@gordonjohnston8321]

Interesting video. I would agree with the concerns about complexity particularly if you are attempting to build your own server. I think where GraphQL really shines is in solutions like Hasura and Postgraphile where the schema is very tightly coupled to a database. The coupling means you get optimised SQL queries that avoid the N+1 query problem.

[@hswolff]

Yeah other solutions are great, but it's another layer of abstraction on top of GraphQL. So even more to learn and more to maintain! Which...may be fine, but I like to be honest with how many dependencies I'm adding to solve the problem at hand. Postgraphile looks very interesting! Thank you for sharing!

[@JeffBarczewski]

Configuring a server on how to resolve graphql queries is not really an abstraction, it's an implementation detail. You have to learn how to configure any graphql server. A small amount of configuration enables a ton of functionality.

[@-_-unseen-_-]

I plan to implement GQL and REST together. GQL seems to be great for queries but I can use REST for the mutations create, update, delete keeping things simple.

[@zomakaja]

As a beginner, it literally took me weeks to get GraphQL, Nextjs, Apollo Server and Client, and Postgres all working together. The complexity is real. Or maybe I'm the only one.

[@adamtak3128]

You're not the only one. Getting ApolloClient to work with Next.js was so annoying...

[@axelreefman]

I use strapi cms running in a docker container. It auto generates the api for you with both REST and GraphQL available. It can use Postgres as it's Database. strapi.io

[@m-zelinka]

@@adamtak3128 only because next.js is a hybrid framework, that means you need to configure ApolloClient work both on the server-side and client-side. This should be solved, once plugins are here!

[@khandoor7228]

Agree with you Harry! Thanks for saying it!

[@hswolff]

Thanks for watching!

[@ApichartNakarungutti]

I only use a portion (strongly types, self-document, responded filter) of GraphQL, because its complexity, I tried other options but fall back to GraphQL, feel like love-hate situation :/

[@MasterTeeee]

... Weirdly, the only solid criticism that you've given is, "GraphQL is hard". That doesn't mean that it's not great. Just that the tooling isn't there yet. If a project doesn't require GraphQL, then it's probably fine to not bother, and stick with REST, as it'll likely result in a project being cheaper, just because of the developer time that needs to be spent on it's efficient implementation. However, if you NEED GraphQL's features, then you NEED them. Plain and simple.

[@rickvian]

Thanks! Enjoyed your video, definetly will learn more from you Wolff!

[@adamyee523]

Caching is only part of the solution when addressing the N+1 and naive data resolution. DataLoader can solve many inefficiencies in a graph without introducing caching. DataLoader isn't just for GraphQL - I would use it in any aggregating server (BFF). Typically, GraphQL aggregates on top of REST, which is easier to cache. Even when GraphQL directly resolves from a database, it's pretty standard to have a cache layer supporting db access for performance. I think over time these become necessary complexities for a well balanced and healthy application.

[@zomakaja]

Thanks for the video. It was well reasoned.

[@user-js7ud9du2y]

what i really wanted from graphql is just a json manipulator that is schema-less select queries . i don't care if i have to call differently for doing insert or updates

[@andrewobrigewitsh]

The biggest advantage is actually the data Graph, 2 is its typing, 3 is getting exactly what you need. The problem with GraphQL is that the main frameworks don't have strong opinionation, this leads to unneeded complexity and people doing things in very weird ways. I think code first is also better for beginners as the schema is radially just a duplication of your resolvers.

[@TroyCSchmidt]

The flexibility in a typed API that can handle dynamically determining fields returned is worth the additional complexity. The performance I have seen implementing GraphQL with smaller more discreet queries instead of trying to find one size fits all larger queries has been night and day. Also with smaller queries and more executing it makes it possible to do incremental loading of the UI easier.

[@_shulhan]

I am happy that I found voice in my head.

[@puyanwei]

Great vid, would love to see a code comparison/example on how your using REST to do typical GraphQL stuff. I do mostly agree, the learning curve and setup is quite a lot, and with our codebase we ended up over abstracting which ended up making some things confusing.

[@hswolff]

Interesting question! I'm being very care free about my endpoints. Not even sure they're following REST tbh - just exposing what data I need.

[@theories1972]

Isn't the dataloader provides caching that solves the N + 1 issue?

[@malikbrahimi7504]

Honestly, because GraphQL is a graph of nodes as it's name implies you essentially end up making resolvers which in turn ends up resembling REST business logic except you have to do the heavy lifting on the backend to create this "only get what you need" environment running. It's like creating a complex linked list and setting a .next attribute between resolvers so to speak. While it does have some benefits on the frontend it's a huge trade off on the backend in terms of the learning curve and development time. Honestly, what's stopping anyone from creating a helper function for DRY and accepting an argument? APIs getUsers and getUsersWithPosts isn't all that different aside from a simple conditional which you can limit repetition with helper functions, in which case GraphQL is just overkill. If you're going to use GraphQL low key just let Prisma do the heavy lifting. Hell use Prisma for REST too! I wouldn't exactly consider it production ready yet because migrations are still experimental but once that's taken care of my workflow is going to be amazing.

[@craigmjackson]

I was also drinking the graphql kool-aid, until I discovered the n+1 problem. I didn't discover it by reading about it, I discovered it by seeing these massive numbers of requests for the same thing. I really didn't want to hack around it, and this was exactly when I gave up on it. Since I generally own the frontend and backend, I see no reason why REST can't get me exactly what I need, with the exactly optimized database queries I need for a particular URL and parameters. I see only one use case for this, to provide a self-documenting client-side experience at the extreme expense of the backend complexity and over-engineering.

[@tommylemon4462]

But you need to write schemas and types for getting the documents, that's another kind of workloads and I don't think it's easier than writing regular API documents manually.

[@elliottmarshall1424]

I implemented this today, didn’t seem all that difficult. There was a react client component npm install bla bla, was super simple. Just add it to the page and it’s now part of the application. Back end just took our already generated table definitions that match the db and use them to generate the schema and link into the correct backend model, add a permission layer and it all just worked… I treated graphql as just another layer between the client and our backend.

[@rtnjo6936]

omg, i'm currently learning graphQL, and it's HRD! soo many thing you should do, when you go to apollographql.com there is tutorial which says : 15 min read this page... i trying to link all what they want from me for about an hour

[@allanpimble7198]

15 minute read? Yes. 15 minute do? NO!

[@nicolasdelfino1]

About time someone blows the whistle on this! 😊

[@veeracs]

The background doesn’t matter to me it’s the content that’s the king 🤴

[@philipfwilson]

Great Job !! Very clear

[@RS-sk7bp]

Misleading, 'click-baity' title aside, this is a good video for someone new to GraphQL and not sure of the pros and cons. You walked through what life with GraphQL could look like compared to REST.

[@sariksiddiqui6059]

You are right..they try to present the advantages assuming you have already setup the graphql endpoint...though wrappers around DBs help..like postgraphile which spins up a graphql server on top of postgres,working beautifully with foreign keys and all

[@sitcomrave]

I got almost impression and started using hasura on backend and mst-gql on client. And things just got fine. If you want more control on backend replace hasura with own server.

[@hswolff]

Yeah, Hasura is great! I just don't like that it's vendor lockin and also requires you to do things the Hasura way...which isn't GraphQL anymore.

[@koistya]

Right, vendor lock in is not a joke. Building a GraphQL API server using graphql.js is pretty simple. See github.com/kriasoft/nodejs-api-starter

[@bkc3546]

Can you specify what vendor lock in? I just started using it

[@JeffBarczewski]

Hasura solves most of what you complained about. It is open source and works with other graphql servers or even REST besides Postgres. It's not any more lock in than using something like Apollo.

[@hswolff]

I’d say it is more of a lock-in due to it being written in Haskell, making the cost to fork way higher than Apollo.

[@mberoakoko24]

Challenge accepted , basically everything is hard for me , so this will also be learnt like the rest.

[@moshericoe]

hahaha "...like the rest"

[@benjamingyuro5584]

My biggest pain with GraphQL was directing the queries to the correct services. With Rest I can easily set up these rules based on the URL path. With GraphQL these queries need to be unfolded and well understood before they even hit the service which supposes to handle the business logic. GraphQL looks amazing from React POV, no need to transform data, reduce the number of calls from the client etc. But the way it does that isn't free. Those data transformations, multiple queries to different services are still needed to be done somewhere. It could hide, in which case can cause huge performance issues. Sometimes developers tend to lean to these hidden solutions because those seem simpler and nicer on the PR. Hidden solution = complexity out of control. Also with GraphQL, it is really easy to "accidentally" handle business logic on the client-side. 😱

[@appl3s0ju]

10:26 lol sorry, can i get you started on the graphql subscription? im curious..

[@kasvith]

To solve under fetching/over fetching you gonna spend a whole lot of time and make your app more and more complicated. I'm on your side too. We tried to move our REST to GraphQL and realized that we gonna add whole bunch of dependencies like Apollo Server etc and gonna be bound for it for eternity. No that's not gonna happen.

[@RedCloudServices]

how does REST accomplish subscriptions or single UI to federated schema? It would have been fair to compare each pain points w gql to it’s rest counterparts?

[@lightningspirith]

Would like to watch you talk about what differences or improvements GraphQL shows over SOAP webservices.

[@greendsnow]

Since KZbin made the Dislike data invisible to the viewers... Such videos can make into unsuspecting devs' playlist... This is your fault KZbin!

[@MrSandeep1992]

Agree with most of it, but I think subscriptions are very easy to setup with GraphQL especially if you are using client library like Apollo vs setting up web sockets manually

[@camelcai]

I use gRPC. I feel there's too much magic in GraphQL.

[@alexandersumer4295]

gRPC is designed for service-service communication, not client-server communication. GraphQL is designed for client-server. Apples and oranges.

[@horacioh]

I blame @benawad on this one... XD

[@hswolff]

Haha! Yes :D

[@js_programmer8423]

For me graphql is easier than rest , but I somewhat agree because you are suppose to set your own Apollo server error codes manually which should automatically be done

[@ngneerin]

I'd love if ORMs and ODMs come with graphql support and make it easier, cached, and optimised.

[@tommylemon4462]

github.com/AutoGraphQL/AutoGraphQL

[@asdqwe4427]

I think t that most people really use it for the schema. It was invented at Facebook too that they didn’t have to write a backend for fronend for each client. Most of us only have one client. I’m happy making a non-standard http endpoint on my test api if there is a use case for it, I’ll do that a few times before reaching for gql

[@jakeave]

Yeah, relay and graphql, postgraphql, it just means it takes me updating 3 repos to get a one line change done.

[@jhonatanparedes7198]

What a great video. Thank you for the insight. It's wild to see so much knowledge needed to make a request.

[@armandorueda8988]

Yes GraphQL and Relay are overkill for personal projects for example. And learning all their abstractions is insane for simple projects.

[@tommylemon4462]

GraphQL solves some small problems while brings more difficult problems. I think it could be used as a gateway for reducing the workloads of aggregating APIs. While it's definitely not suitable for neither RDBMS(MySQL, PostgreSQL, Oracle, DB2...) or static typing languages(Java, C#, Go...). Here is a much better solution by Tencent. APIJSON has much more functions, performs better and is safer than GraphQL. You don't need to write schema, type, resolvers, etc. Actually you don't need to write any code for CRUD functions with databases. github.com/Tencent/APIJSON/blob/master/README-English.md

[@gsgmedina]

Excellent video! What is your opinion about OData?

[@exactzero]

Another great video. As a solo dev, I am more productive building REST APIs. Btw, can we expect more Next.js vids? :)

[@hswolff]

Maybe >:D

[@htmlfivedev]

Very honest and very funny ... (some how)

[@n1ru4l]

The problem with subscriptions is that most people who use them should actually be using live queries. Updating the cache manually sucks. Unfortunately, there is no major "open-source" solution for live queries that do not lock you into using a specific type of database that I am aware of.

[@hswolff]

Yes! Thank you!

[@avi7278]

a "smart box" ... you mean a box with what's inside of it written in marker on it?

[@bestcoders]

nice and educative but the n+1 problem is not specific to grapql.. you must always take care of that in every server you build be it rest or graphql

[@osazemeusen1091]

its easier to solve n+1 problems in REST IMO

[@adamhenriksson6007]

Not sure why you would say that GraphQL API's gives you a lot of features that you otherwise have to implement manually and then say that it's complicated like it's a downside. The alternative is worse. The N+1 database problem is very easily solved, while the query is basically impossible in REST. Instead of stampeding your DB you stampede your network. This is just like deciding to use vanilla JS on an interactive/SPA site because "React/Vue requires that you learn a lot and it's hard". I get that GraphQL can be overkill on a vast majority of projects if you don't know what you are doing, but that argument was basically a footnote in this video where most screen time was "Wow, all these features that are virtually impossible to implement yourself in a commercial application are hard to learn". A framework is not a religion, it's a set of tools you can use to make your life easier when you need it. I know that you made this video for yourself and fans to explain why you don't use GraphQL anymore, but in reality you can change the title from "Why I Don’t Use GraphQL Anymore" to "Why I Don’t Use GraphQL Anymore, And Why You Should Too", because that is how most people will read it. Most people want to learn when watching tech KZbin, especially if you include tech keywords in the title.

[@MrEnsiferum77]

It's not the problem in Grahql or Rest, it's problem of solving business domain problem wtih technical thinking in mind. If u do DDD and unit tests u can have everything prepared well without rest or graphql, and of top of that u can then think of what is best suitable for u. but lead developers and clients are nuts, so DDD doesn't make sense, we are just stuck forever with this frameworks, for re-building same and same apps. oh yeah we have docker now, woooo

[@lardosian]

I think DataStore from AWS is another alternative to Apollo but I'm fairly new to the game so I'm no expert. I'm in my first dev job (solo!!) using AWS Amplify framework which uses graphql heavily, but Amplify does a lot of the heavy lifting. You write the database schema in graphql and Amplify then creates all the CRUDL for you. Because I'm making a PWA with React I chose to use this new DataStore database from AWS which is an offline first approach. DataStore creates a local db on the client and synchs with the DataStore database in the cloud. So to get data from the back end I just query the local database which is quite straight forward and the the graphql stuff is taken care of for me with DataStore. Man I hope what I'm doing is correct because I'm on my own in a startup. I made the decision to go with DataStore after watching some AWS videos. One thing that is difficult is pushing database schema updates, when the database synching breaks thats when the fun starts...yikes.

[@swish6143]

Can you make a video on Graph QL subscriptions and vue?

[@Joengethe]

The solution for N+1 is using data loaders. Caching can solve it but caching it's not the recommended way for this particular problem.

[@KeyKeeper86]

If I understand correctly, your point is that while GraphQL offers benefits, it also comes with own problems AND steep learning curve. These are some good reasons to consider avoiding GraphQL. However, as someone who's unfamiliar with GraphQL I am not convinced that these claims are justified. Every single tech has drawbacks, so expecting GraphQL to not have any weak sides whatsoever would be strange. The only question is whether the benefits overweight the drawbacks. Things like strongly types API scheme, schema stitching, and others are HUGE. I didn't quite get the drawbacks are really as bad as the benefits. Even the example with a need of cache in front of a backend/db is not very persuasive because it's more of a corner case in my view. As far as the steep learning curve goes. I only know a handful of techs that have really nice ROI when it comes to learning. React is a great example. But again, every dev expects perpetual learning. It's inevitable.

[@eugenpaval]

Well put!

[@eugenpaval]

It's definitely more complex, because as you said, complexity is moved on the server. Imagine a SQL server without the query language. Instead a patchwork of APIs grant clients access to data. Definitely simpler to implement server side but the client suffers. In fact it will be unworkable after a certain point. Having said that, GraphQL is certainly more suited in larger projects and it is also a great way to give uniform access to other Rest APIs that come with their own queerness. To your credit you do mention the advantages, strong type system, data shaping, tooling. In my opinion just these alone make the case for GraphQL. A gql query can be written in an environment where there is interactive documentation and auto-completion. Queries are parameterized in a standard way and the result is always in the shape asked by the client. Good stuff! Now, about the disadvantages you mention. Sure, it could be complex to implement but the complexity is not being brought by GraphQL, the technology itself. It exists as part of the problem you want to solve and having that in a single place is preferable to split it between the server and the client.

[@WebDevCody]

I don’t even know what the issues are with restful apis.. I tried graphql and wasn’t sure what it really solved.

[@BobbyBundlez]

im a noob. but i can see the constant requests being a problem. also state management tools like apollo allow for caching of data which saves a lotttttttt of expensive shit Broooo blaze 420 dude

[@MascleGinger]

I started to learn graphql but you mentioned about inability to cache post requests on the client and n +1 problem and it's a big drawback, but graphql is great nevertheless

[@victorbrylew1775]

I don't get flexible schema as advantage. For example we have huge schema with several nesting levels and hundreeds of arguments/fields. This schema make possible usage of millions of different requests to backend. Meanwhile in reality we will use tens or hundreeds of requests from this huge set. So we are paying by all server side complexities for nothing. Or maybe it will be more correct to say that by price of hell on server side we buy client side ability to switch from one attribute fetching to other. I'm happy for JS-friends but isn't this price too big? Isn't it like buying wonderful lamp for $10000?

[@henrikholst7490]

You mention strongly typed schema in GraphQL as a benefit over an Rest API. But for Rest we have OpenAPI... Doesn't that solve the problem in some sense?

[@darkasblue]

so you say openapi is better than graphql ?:)))))))

[@dlroWolleH]

You sound like vin diesel.

[@tonyhill5966]

Love the paradoxical objective and subjective views. Are you concluding that it all comes down to the specific use case? I'm currently deciding if I should implement Gql and I have just come across having to implement caching and a slew of other mechanisms.

[@aaronrs2002]

May I ask why not simply filter the keys & values you need out of the data before sending it back to the client using basic javascript/node.js?

[@shanonjackson5528]

Harry you may want to check out Hasura's implementation of GraphQL, no N+1, no linear complexity either (+1 for each nest). 1 Extremely performant query for all your data autogenerated for you from your postgres database schema.