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.
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.
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
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.
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.
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 :)
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.
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
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.
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!
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.
@@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.
@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.
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.
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.
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.
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 ;)
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.
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.
@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.
@@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.
@@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.
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!
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
... 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.
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.
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.
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.
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
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
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. 😉
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 😂.
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
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 :/
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
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
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.
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.
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.
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?
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.
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.
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.
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
@@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!
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.
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 RU-vid, especially if you include tech keywords in the title.
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.
Agreed! A lot (most?) of the problems highlighted in the video are solved by moving to a higher abstraction like Hasura or Postgraphile. Writing all your own resolvers is where a lot of the pain has been, I think. Postgraphile is so underrated, using it in production right now and wondering why it's not more popular. Postgraphile's plugin system has a surprisingly large surface area which makes it way more useful than just auto-generating CRUD resolvers. I think Postgraphile needs more advocates.
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!
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.
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.)
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.
So, you removed your AC by now, because installing it was very complicated? My Company runs a small DWH for a customer and I provided the GraphQL-Endpoint. Yes, it was some work, but I think, its better than plenty of rest-endpoints.
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.
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.
@@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.
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.
@@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.
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.
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
@@RakeshWaghela if you have an MVP spawn some VPS and put server on it. When the time comes and this VPS is no longer capable of providing data to all requests just scale it and then transfer your project to lambdas and microservices. You can use Amplify when this time comes without much effort. Regards!
@@RakeshWaghela It depends on the code implementation. U can write application with single codebase and run it in every environment. Thats not true that you are locked if you are smart.
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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
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.
I wondering and not found any answer about Graphql makes me fetches all data from database e.g mongoose model and select data after this fetching from the client side, this is bad for performance true or not ?
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
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.
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?
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
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
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
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. 😱
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
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
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.
@@elephant_888 But is this really the problem? If you have REST and you actually do resource oriented API design, you'd have the N+1 problem in the client... What you can do is instead of having this caching layer, or data loaders, is checking in the queryContext whether it requests the nested stuff and branch accordingly. No need to overload the db or keep stuff in memory and do N-more queries in your backend
@@nikunjchaudhari9064 sure. The speaker’s point was that graphQL wasn’t magic and there are a good number of things to think about that can make it complex if you’re coding it from scratch. Today a lot of these problems have been obviated by tools like Postgraphile and Hasura, but it’s still a fact that REST endpoints are easier to get off the ground. I love graphQL and I use it for most of my organization’s projects. However if you’ve only got a tight deadline, it would be silly not to consider REST.
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.
