The worst thing that can happen with any app (web, desktop, mobile, etc) is that due to bad backend design/architecture they should call multiple api requests to display some data it doesn't matter if it's REST API or Graphql.
Just think of if you order a notebook and in stead of receiving a whole notebook at once you'll get it in part first keyboard some time later display then other parts. For the user app is a complete product why user have to get parts of it? Of course there are some optimisation technics and data is loaded in parts but the reason why they were created in not just a poor internet connection. User would prefer any app to be loaded just when the app is opened and data is just there no loaders, no jumps, no weird behaviours.
Of course all these can be solved both with Rest API and Graphql but it requires
a little bit more work and better architecture design.
Performance (N+1 problem)
If you are using node.js there is a tool called prisma (prisma.io) it will help forget about any dataloader.
But keeping in mind that it would be better for user to get all the data for current view at once some problem may occur with Rest API so you'll have to find solution for that.
A lot of modern backend frameworks doesn't solve n+1 problem.
If your are using Rest API it doesn't mean that your backend has better performance. Users don't pay for your backend and it's performance they pay for the data/information they see on their displays, they don't care about your backend and if it has n+1 problem or not. And it's a huge difference when the app has to make 10 http request, wait for them all then app code should somehow merge them and display meanwhile it can be done with just one http request.
Security
Very similar thing can be done even with Graphql. You can secure each query or mutation as you can secure each endpoint when you're using Rest API. It's just a question of architecture and your comfort zone.
If someone doesn't have deep understanding how current tool works that tool won't be helpful. Any tool can be misused. There are no bad or good tools, there are tools that solve specific problem and maybe there are not trying to solve your problem, so developers should choose tool according to their problem.
In my company that i'm working at, we discovered that prisma sql query are poorly optimize...
We completely removed Prisma from the code and now we are writing our own queries.
I think that there is a world between REST and GraphQL.
For front-end application, there is a need to create something specific for the jobs (presenters). Most of us are not developing a Facebook that has the complexity of displaying lots of variable data.
In most application that I have worked on, we always ended up writing services (note that I'm not using the word REST) that were used to present data for specific parts of the application. Mutation were also tailored to the specific need.
The architecture was usually FE -> Presenters -> Business
Presenters are specific to the view (whether that is web, mobile, or mobile app).
This does not suite all but when the team is taught for defining the contract and making them evolve according to the need.
I don't think microservices, which is the nearest you could come to REST, have ever been suitable for frontend consumption especially for the reason
This isn't quite right for a few reasons.
Agreed users don't care about n+1, unless that means things are slow to load. Then they care heaps.
GQL doesn't cache. Never will you get a 304.
GQL can't make use of client side service worker caching either.
It's not a huge difference if a Client makes 10 calls anymore because of multiplexing.. In fact if those 10 calls hit different pods/severs/dynos then the call is much faster. Each server has to grab a small optimised bit of data, where with GQL the fast bits of the query have to wait for the whole data to be built.
Lazy loading or partial loading of the data gives the user something to see while the rest is being load..
Now.. when you want to upload or download a file. How does GQL handle that. I've not been around all that long, but I always see people falling back to REST for these.
GQL is not great for errors. All posts return 200. If I say you got a 404 or a 401 or 403, then you don't have to think about what those mean. Each GQL build has to build its own error mechanic. Moving jobs means one has to learn new error paradigms.
Agree about how GQL handles security.. One can set limits right down to the field. In that it shines.
EDIT: I keep thinking of other things.. lIke debugging errors from the network tab.. Nothing like 20+ posts to the same endpoint to make finding the call that is returning an error a right pain. I'd take a RED line over a pile of 200's any day.
Just defining schemas (objects with field and types) automatically gives you a complete GraphqlAPI + Pretty CMS. All relationships are connected. It uses Prisma on its backgrund. Can let you extend and customize mutations, triiger actions on hooks, add layers of security. Authentication, authorization and caching included.
I can start a backend project in a couple of hours.
My favorite project in 10 years of developing as a backender
I'm talking about a special kind of app, a project that's just getting started.
The worst thing that can happen to a new project is no one uses it. I believe the main problem at hand is validating a business idea, not worrying about sending 5 requests instead of 1 request.
There are definitely ways to have performant and secure graph. It does require a level of comfort zone with GraphQL. It does require additional tooling. It might also introduce some black boxes as well if we are blindly using these tools without understanding the internals.
Choosing the right tool for the job is very important. We have to consider the stage of the product and the size of the team when choosing initial set of technologies.
If I'm working on a mature project that already has product market fit, of course I would prefer to work with GraphQL. These arguments would be poor if I was talking about mature apps.
To your point about reaching for a tool too early in a project, a microservices architecture shouldn't be utilized before the "seams" of the business domains have been clearly defined.
I'm sorry but your arguments are very poor.
The worst thing that can happen with any app (web, desktop, mobile, etc) is that due to bad backend design/architecture they should call multiple api requests to display some data it doesn't matter if it's REST API or Graphql.
Just think of if you order a notebook and in stead of receiving a whole notebook at once you'll get it in part first keyboard some time later display then other parts. For the user app is a complete product why user have to get parts of it? Of course there are some optimisation technics and data is loaded in parts but the reason why they were created in not just a poor internet connection. User would prefer any app to be loaded just when the app is opened and data is just there no loaders, no jumps, no weird behaviours.
Of course all these can be solved both with Rest API and Graphql but it requires
a little bit more work and better architecture design.
Performance (N+1 problem)
If you are using node.js there is a tool called prisma (prisma.io) it will help forget about any dataloader.
But keeping in mind that it would be better for user to get all the data for current view at once some problem may occur with Rest API so you'll have to find solution for that.
A lot of modern backend frameworks doesn't solve n+1 problem.
If your are using Rest API it doesn't mean that your backend has better performance. Users don't pay for your backend and it's performance they pay for the data/information they see on their displays, they don't care about your backend and if it has n+1 problem or not. And it's a huge difference when the app has to make 10 http request, wait for them all then app code should somehow merge them and display meanwhile it can be done with just one http request.
Security
Very similar thing can be done even with Graphql. You can secure each query or mutation as you can secure each endpoint when you're using Rest API. It's just a question of architecture and your comfort zone.
If someone doesn't have deep understanding how current tool works that tool won't be helpful. Any tool can be misused. There are no bad or good tools, there are tools that solve specific problem and maybe there are not trying to solve your problem, so developers should choose tool according to their problem.
👎
I wanted to write some of these as well
In my company that i'm working at, we discovered that prisma sql query are poorly optimize...
We completely removed Prisma from the code and now we are writing our own queries.
I think that there is a world between REST and GraphQL.
For front-end application, there is a need to create something specific for the jobs (presenters). Most of us are not developing a Facebook that has the complexity of displaying lots of variable data.
In most application that I have worked on, we always ended up writing services (note that I'm not using the word REST) that were used to present data for specific parts of the application. Mutation were also tailored to the specific need.
The architecture was usually FE -> Presenters -> Business
Presenters are specific to the view (whether that is web, mobile, or mobile app).
This does not suite all but when the team is taught for defining the contract and making them evolve according to the need.
I don't think microservices, which is the nearest you could come to REST, have ever been suitable for frontend consumption especially for the reason
Unleash the trolls :-)
🤔 REST is not microservices, or nearest... Microservices is much more 🙌
This isn't quite right for a few reasons.
Agreed users don't care about n+1, unless that means things are slow to load. Then they care heaps.
GQL doesn't cache. Never will you get a 304.
GQL can't make use of client side service worker caching either.
It's not a huge difference if a Client makes 10 calls anymore because of multiplexing.. In fact if those 10 calls hit different pods/severs/dynos then the call is much faster. Each server has to grab a small optimised bit of data, where with GQL the fast bits of the query have to wait for the whole data to be built.
Lazy loading or partial loading of the data gives the user something to see while the rest is being load..
Now.. when you want to upload or download a file. How does GQL handle that. I've not been around all that long, but I always see people falling back to REST for these.
GQL is not great for errors. All posts return 200. If I say you got a 404 or a 401 or 403, then you don't have to think about what those mean. Each GQL build has to build its own error mechanic. Moving jobs means one has to learn new error paradigms.
Agree about how GQL handles security.. One can set limits right down to the field. In that it shines.
EDIT: I keep thinking of other things.. lIke debugging errors from the network tab.. Nothing like 20+ posts to the same endpoint to make finding the call that is returning an error a right pain. I'd take a RED line over a pile of 200's any day.
Have you tried keystonejs.com?
this backend framework is a game changer.
Just defining schemas (objects with field and types) automatically gives you a complete GraphqlAPI + Pretty CMS. All relationships are connected. It uses Prisma on its backgrund. Can let you extend and customize mutations, triiger actions on hooks, add layers of security. Authentication, authorization and caching included.
I can start a backend project in a couple of hours.
My favorite project in 10 years of developing as a backender
I'd suggest hasura.io/.
I'm talking about a special kind of app, a project that's just getting started.
The worst thing that can happen to a new project is no one uses it. I believe the main problem at hand is validating a business idea, not worrying about sending 5 requests instead of 1 request.
There are definitely ways to have performant and secure graph. It does require a level of comfort zone with GraphQL. It does require additional tooling. It might also introduce some black boxes as well if we are blindly using these tools without understanding the internals.
Choosing the right tool for the job is very important. We have to consider the stage of the product and the size of the team when choosing initial set of technologies.
If I'm working on a mature project that already has product market fit, of course I would prefer to work with GraphQL. These arguments would be poor if I was talking about mature apps.
To your point about reaching for a tool too early in a project, a microservices architecture shouldn't be utilized before the "seams" of the business domains have been clearly defined.
Absolutely. Microservices is not the right approach when we are just trying to validate a business idea.