I see GraphQL and other tools created by FAANG companies being used all the time by 1-3 person teams. Their applications are often slow and poorly made. I say that because initially I felt like maybe I wasn't being "professional" if I didn't use these tools, but actually using their applications reassured me that I was going in the right direction.
I see people use GraphQL as the new ORM. I see it used by people who don't have that much experience with databases. I see it used by people who have nothing much to do. It is sometimes about cost requirements. You can just spin up one of those automatic graphql servers that creates the entire backend for you. Sure it doesn't have any logic or security or performance, but it was quick to get up and going and the client is not experienced enough to notice in the beginning. It is often used with Apollo client, so these inexperienced developers then have all kinds of caching issues due to the automatic caching the client does that they don't really understand.
I see it having an application at FAANG scale, where there are teams of front end and back end people, and front-end people can just create the UI without talking to the back-end people. I see it being used at places with enough scale to have multiple graph databases, not SQL databases, or multiple types of databases that need to be unified.
That isn't where it is used in most cases though. It ends up being a very limited version of SQL that is slow. I think it would be good for maybe a public API.
Yes exactly! GraphQL would be great for a huge company with multiple front end and backend teams that are a challenge to communicate between. It standardizes and simplifies things for that massive organization and alleviates the pain of communicating API changes across such a big organization.
If you are one small to medium sized team. Or honestly even 2 small to medium sized teams, GraphQL is overkill. The people working on the API for your frontend are either right next to you, or even you yourself. So there’s no need to introduce this big backend framework with a strict API. There’s just little to no process or code quality benefit for small teams. Unless someone on your team is absolutely terrible, and that terrible person is going to cause problems anyway.
I get your point. But to be honest, why is a well designed REST API with a developer portal and amazing documentation not capable of delivering exactly that? Take Stripe for example. Would Stripe be as successful as it is with GraphQL? If yes I believe they would have had to build a lot of additional tooling to make it work. The same they did for their REST API by the way. They invested a tremendous effort into their documentation and developer portal. I guess that's the essence of a successful API strategy. Whatever technology you choose, you must invest in the developer experience, hence build good documentation, example use cases, etc..
I used GQL on projects before. I never used those 'ready-made' tools though. All the resolvers were written by hand and the SQL queries as well (in the ORM specific language).
GQL works well when you have unstructured data that 'links' to other or in places where you need to query data in various different ways, with different joins that REST doesn't help (or you end up creating a querying language on top of your REST endpoints anyway (/clients/?age>2&link=business,jobs&business.broke=false&etc etc etc)
Then you need to do this for pretty much every REST endpoint that may need this functionality. With GraphQL the server knows how to fetch the individual entities along with the filters, and create a nice graph of it for you (and you can optimize the resolvers if you dont want to have a lot of DB calls).
Saying people are using GraphQL as the new ORM is the same as I saying people are using Ruby on Rails (and their scaffolding) as the new low-code solution.
Most of the negatives you're observing seem to be a consequence of people not knowing how to use GraphQL well. This is definitely a problem worth solving, but it's also not a problem with GraphQL per se -- if you snapshot the usage profile of any high growth tech, you'll see that at any given moment in time most of the people using it don't have a lot of experience with it, that's just what growth looks like.
My opinion here is somewhat unusual -- even with the GraphQL world, but I think you can get benefits from using it even at teams of just 1 engineer. But you _definitely_ don't need to be anywhere close to FAANG scale for it to be worth the investment.
> Most of the negatives you've observing seem to be a consequence of people not knowing how to use GraphQL well.
People who know how to use GraphQL aren't likely to be dissuaded from using it well by a blog post or some internet comments, so this is an argument in favour of telling people “if you have to ask, GraphQL isn't the right tool for the job”.
Perhaps. But there's an angle here which is there's a VC goldrush of GraphQL ecosystem solutions, many of which (IMO) probably aren't good ideas. So there's a lot of marketing push towards solutions which represent many of the negatives the post I was replying to highlighted.
I think GraphQL actually _is_ the right tool for many of the jobs people are using it for (API layer for 1st party clients), but they're often using it poorly due to many of these tools having slick APIs that let you be productive alarmingly quickly -- you only feel the pain much later.
I use GraphQL all the time in conjunction with PostGraphile https://www.graphile.org/postgraphile/ and let me tell you, it's definitely not slow. If anything it is very fast. But just like REST or anything else, if you do a poor implementation you will get a poor result: garbage in, garbage out.
> I see GraphQL and other tools created by FAANG companies being used all the time by 1-3 person teams.
GraphQL is touted as a technology which saves developer time by avoiding the need to develop REST APIs, and instead just expose your database to the world and let your frontend just get whatever data it needs.
No wonder you're seeing small teams using it. It's not because of FANG, not because of cargo cult development, not because of incompetente. It's because small front-end teams don't spend their scarce resources on areas where return of investment is limited.
> GraphQL is touted as a technology which saves developer time by avoiding the need to develop REST APIs, and instead just expose your database to the world and let your frontend just get whatever data it needs.
Where are you seeing this? There are a couple of solutions that follow this model (e.g. Hasura, Postgraphile), but it's not an approach recommended by any of the creators of GraphQL, or the bulk of its users.
I’m the maintainer of PostGraphile and I also don’t approve of “just expose your database to the world and let your frontend just get whatever data it needs.” PostGraphile is a tool to help you to rapidly build performant and secure GraphQL APIs that follow many of the GraphQL best practices out of the box. It is not a “run and done” solution, you do have to put a little effort in to build a decent API but we give you the tools to achieve this in a fraction of the time of rolling your own, and probably with better performance also. Our extensive documentation is peppered with advice on how to craft your API, not to expose more than you need, not to expose complex filters (instead adding specific filters the frontend needs), how to include/exclude things, how to add in additional fields, types, remote content, etc. Our users are generally very happy, we’re just not very good at marketing ;)
This is the part I was focusing on, sorry if there was confusion. For context, I've been working with GraphQL since June 2015, so I'm pretty intimate with the topic.
It's worth noting that those slogans you quoted are from graphql.com rather than graphql.org. The latter is the official site, the former (.com) is owned by Apollo and isn't official in any capacity -- something I personally find to be an extremely questionable situation. GraphQL's actual slogan is "A query language for your API".
While you're right I see another trend as well. Multi national Fortune 500 companies with many many sub organizations and hundreds or thousands of engineers who try to find a way to scale APIs for them. Not saying REST is no solution to them but GraphQL, especially with schema stitching and/or federation can definitely help in this case to organize the API landscape.
I see people use GraphQL as the new ORM. I see it used by people who don't have that much experience with databases. I see it used by people who have nothing much to do. It is sometimes about cost requirements. You can just spin up one of those automatic graphql servers that creates the entire backend for you. Sure it doesn't have any logic or security or performance, but it was quick to get up and going and the client is not experienced enough to notice in the beginning. It is often used with Apollo client, so these inexperienced developers then have all kinds of caching issues due to the automatic caching the client does that they don't really understand.
I see it having an application at FAANG scale, where there are teams of front end and back end people, and front-end people can just create the UI without talking to the back-end people. I see it being used at places with enough scale to have multiple graph databases, not SQL databases, or multiple types of databases that need to be unified.
That isn't where it is used in most cases though. It ends up being a very limited version of SQL that is slow. I think it would be good for maybe a public API.