Question about GraphQL
I'm working on a fairly large (mobile app) project with a friend
The app itself is written in Kotlin and our backend service is written in C# using ASP.NET, we use EF Core to interact with our database, my friend has made a suggestion that we could use GraphQL for the backend service, now while I see the advantages that GQL could bring to the table I also see other things:
- lots of issues that GraphQL is supposed to solve feel like are already easily done with our EF Core structure or the Model structure in general
- users being able to request the data they Want sounds like a nightmare to me
- single endpoint for a project this large may serve lots of disadvantages over time specially since we'd basically throw out the whole API controller thing where we can easily manage what class does what
What do you guys think
10 Replies
What kind of functionality does the app provide?
As a rule of thumb I'd say if you have to ask yourself why you need GraphQL, then you probably don't need it
It has its uses
But it's similar to the microservices vs monolith discussion. One thing was invented to help large enterprises scale their service due to very specific needs, and not everyone has these needs
GraphQL shines when you have a data driven API and maintaining over / underfetching would mean significant effort in a Rest api
But most apps are probably functionality driven and do not benefit a lot
social media app
im used to the REST approach specially because the backend is specifically made for that app, which means either way there should not be any over or underfetching which for me seems like the biggest "advantage" of GQL but I just cant wrap my head around its use case
the issue I have is that i just cant imagine 1 endpoint doing the work of 100 for example, id much rather create 100 fully polished endpoints (that I also document well enough to keep up readability and maintainability) that each do their own thing than a 1 for all approach endpoint
have you tried some graphql services to at least have an idea of how it is to use it?
i didnt, my friend just recommended it to me today and Ive read the examples on the page
i dont have any real world experience with it yet but i wanted to ask if its even worth learning or using for such a large scale project coming from a strong background with REST (and the feeling that EF Core seems to already allow me to easily do the things GQL strives to "fix")
You should definitely try it. If your data is very complex and maintaining a lot of endpoints to deliver specific data is where graphql could solve your issues. With REST the requests to fetch a "full" dataset can also become cascading, so the client might end up taking longer to gain access to all they want. I encourage you to try graphql, but if you're just getting started and the data is likely relational (for a social media platform), then you'll likely be better off starting with REST imo
Graphql was invented by Meta to solve Meta problems
Especially if you are experienced with Rest, it's also an investment to learn graphql now
to get a basic understand of the syntax of it you just a few minutes
if after that the idea is still not a no then you can see how it integrates
graphql has still its issues
ill definetly take a look at it, i could use it on a project im working on atm which is a backend + app to further strenghten what I already can do
it not a set backend yet so I still have time to implement it to try it
i mean the app (from my original question) is supposed to get a secondary public API maybe it makes sense there to implement a public REST API as well as a public GQL API
The most interesting thing HotChocolate does is data loaders
If you're going to be doing graphql, use HotChocolate
They have a Slack
you could spend a lifetime helping everyone on the hotchocolate slack
It's a really good library but the documentation is often lacking that one bit of info you really need (or is 2 versions behind, with the up-to-date stuff being in a YT video
It's definitely the top choice for graphql without a question though
so the way id do this from the current point:
Our service API is cut down to the exact needs of the app already since the api is written specifically tailored to its needs but our public api will get a REST API and a GQL API so actual users can fetch data they want rather than our service API (which btw i under no circumstances want anyone to freely use we put heavy security measures in place to ensure that (which is another reason why i dislike the idea of GQL for the "private" API of the app))