Should I implement GraphQL?
In the past couple of months I'm having this slow down with development of my app, so it got me thinking - maybe I should get into more recent tech stacks to work faster and be more flexible.
I usually work with Django + templates.
I recently started tinkering with Nextjs and GraphQL.
I now understand the theory + basics, and I think it can be valuable in the future. Definitely making the frontend much more flexible.
- I'm worried that maintenance will be hard over the long term
- Was wondering what you guys think - how much time is this going to demand? the move from Django to Django + Next + GraphQL
- Can I do this gradually? meaning, serve only some of the pages with Next & GraphQL
(I'm quite experienced with code, but every new tech has its learning curve)
Thanks in advance,
Trending on Indie Hackers
No. GraphQL is great for a larger team with separate teams building the frontend and backend. For a solo coder, it’s a lot wasted effort for very little gain.
I kindly disagree, having a GraphQL API speeds you up like crazy on the frontend even if you are alone for most(if not all) of the standard apps.
I do agree that if you implement it manually in the backend with every type and so that part would be more effort.
However auto generating it in the backend with hasura or amplication it's gonna be way less effort than building a restful API.
The frontend speed up is from more work done by the backend… so using Hasura is a good hack to offload that, assuming you don’t mind the tradeoffs of being dependent on them. Good idea 👍
"the frontend speed up is from more work done by the backend" - fully agreed
If you do mind the tradeoffs of being dependent on hasura(it does have an community edition open source, how about using amplication.com?
That is also OS you actually get the generated the code to modify and do whatever, the stack is NestJS and for ORM Prisma.
JavaScript is the last language I’d use on the backend. I’d use Elixir, or Rust if there were extreme performance needs. But even Java or C# or Ruby would be better than JS.
oh ok. What if there were extreme development speed needs?
Elixir and Phoenix Framework or Ruby on Rails.
I'm using graphql in my work, and let me just say that it's a royal PITA to deal with. There is a ton of boilerplate, and you'll quickly wish you never integrated it.
I get it for very large products. For indiehackers? No.
Can you share what's the part that's responsible for most of the work? I work with django and seems like graphene can do most of the heavy lifting (https://docs.graphene-python.org/projects/django/en/latest/tutorial-plain/).
It makes sense in the inital phase of development when the api's are not crystallized between frontend and backend teams in big companies. I don't really see any advantage if same person is implementing front/back end.
I don't have any experience in django i am talking from my experience in golang.
You should try ent if you work with go.
thanks for suggestion, i evaluated it however it is not for me. I write schema and queries in sql and autogenrate go code so its not a problem for me. I am familiar with sql and know how to analyze and make queries performant if there is a need with ent i would have to learn new syntax which is only useful for ent and which is not intutive either. It would have been great if ent code can be autogenerated from db schema it would have made it much user friendly.
I have a few thoughts about this based on my own experiences.
Sometimes trying something new in your tech stack can be motivational. It can breathe new life into a stagnant project. I think this point is often overlooked.
To counter the first point, it's almost never going to speed up development by as much as you think. At the end of the day you've still got to work to get something done.
If you're going to try a new tech like GraphQL you should at least spend some time trying to understand what problem it's trying to solve. Facebook created GraphQL to solve Facebook problems. You probably don't have those problems.
Sometimes the real problem is that whatever your doing now isn't working as well as you thought it would. I struggled a lot with implementing REST until one day I realised I don't actually need it. REST is a highly misunderstood and overrated pattern and there's lots of bad information out there about how to do it properly.
Taking the time to properly understand HTTP requests and when to use GET, DELETE, POST and PUT is better than trying to strongly adhere to REST. Just find what works for your app and do that.
Most people that try to implement REST actually end up with a weird RPC / REST hybrid. It happens because doing REST well is actually super hard and don't actually suit most apps. I say embrace it, just go with it and stop stressing.
Thanks for this very well written reply.
I totally agree with your first observation.
And with the rest as well.
Perhaps rethinking about why do I want to implement GQL - the underlying reason might be that I want my app to be more reactive and to enjoy all the recent tech improvements, specifically in everything related to how responsive the app is. I guess that React and libraries like Material UI are things that people unconsciously notice.
Coming from a game development background I absolutely agree that people subconsciously notice these things. Sometimes it's called the "feel". In games, great attention is paid to this stuff because it matters.
That said, your users probably won't notice GraphQL because it's just the layer between the back and front end.
But your users are not the only people that matter. You're doing this for you and that's okay too. At the very least you'll learn something.
Thanks, really appreciate the support and your thoughtful reply.
I love GraphQL, but if you're worried about a slowdown of development, GQL isn't going to help you with that. It's going to slow you down even more. It's a pretty fancy API style which is tricky to get used to. It makes it easier on the frontend, but then it's more difficult and confusing to build things on the backend.
And if you're implementing both the frontend & backend then you really don't get much benefit from GraphQL. When your frontend needs some data, you can just whip up a new backend REST endpoint to serve it. It doesn't really get easier than that. GraphQL is most helpful when the frontend teams and backend teams are totally separate, and the frontend coders want the flexibility to write the queries they need without any backend help.
I am doing both the front and backend. and I understand it should help on the frontend, that's why I thought it might help with the frontend.
Do you have experience with Django + Next + GraphQL? if so, what do you think of the combination?
I've used Next + GraphQL (but not Django) and it works great, no complaints. On the frontend we put the requests inside React-query which also works great.
thanks.
The general rule of thumb is that adopting a new tech:
thanks, yeah I guess this is the common answer to any new tech. the question is whether in this case the general rule rules..
Whether some rules overrules your own decision making process is the question indeed. If it feels the right to do, just do it. I have changed stack on many of my side projects numerous times and even though it's never (or unlikely ever) the best choice from a commercial perspective, you do learn a great deal..
thanks, I'm definitely curious about it, which is probably responsible for 50% of learning :)
I have just finished building useGenerated.com. A CLI that auto-generates the code for CRUD GraphQL API (with NestJS and Prisma). It woks like this : 1. you define the models in Prisma ORM 2. Define how nested the queries will be and the roles required for each operation 3. run a CLI command. I have saved me months worth of backend dev for one big project.
currently is $49 or PPP that should be equivalent of 2 hours worth of work for you. If you would like a demo or do not afford it let me know and we will solve it.
I would say that it depends on your needs and circumstance.
If you have time on your hands and wish to learn GraphQL out of curiosity anyways, I'd say go for it; I'd estimate takes a few days to get the basics down and a few weeks to explore more complex use cases here and there. I'm not sure what platform you're building, but for mobile development (Apollo) GraphQL did miracles — I particularly miss the great automatically-generated documentation that would help streamline development between frontend and backend.
That said , if you're constrained on time and need to move fast, I wouldn't waste time on learning it. We've been working on a MVP this past month and actually reverted back to REST.
There are a lot of comments about graphql being too much for one person/hard to maintain which I'm sure are well intentioned, but using the graphene django library makes graphql extremely easy to use with django. It's quite similar to the django rest framework in how you set it up/connect it to models etc.
I've used it on many projects and there is a little bit of a learning curve to figure it out at first but it's very easy to use once you figure everything out.
I think most people nowadays would advocate using rest api or graphql vs something like django templates and having that front/back end separation. I use a vue app for the front end to interface with the graphql api and it works very nicely, the dynamic data saves a ton of javascript.
Thanks. Yes I'm seeing that as well.
What do you use for authentication on the GraphQL api?
There are several ways to do authentication outlined in the graphene-django docs, but you can also do an array of custom things depending on your needs. I personally don't need to prevent logged in users only for example, but I do overwrite the graphql view and insert my own checks sort of like what's explained here https://github.com/graphql-python/graphene-django/issues/345.
I would also make sure you disable the graphiql interface when debug is off.
Hi!
It vastly depends on your use case, but based on what you are saying, GraphQL should not be your choice.
GraphQL sounds good in theory, but in practice it's much more complicated than traditional REST requests and introduces a lot of implicit complexity around performance, caching etc. Usually, you have to use some dedicated framework that will affect app performance and build size. Writing proper resolvers on the backend is not trivial.
GraphQL's best use case is when you have a team working on a complex backend service that exposes a lot of data, and various teams can perform complex queries with GraphQL. For typical CRUD operations, it's a big overkill and REST is most likely a better and easier option.
NextJS on the other hand is awesome. You can also check https://astro.build/ if you have a more content-oriented project.
Both Next and GraphQL on the front end side are amazing time savers.
Now for some developers in some languages implementing a GraphQL backend can take more time.
There are tools out there that can get you an extendable CRUD GraphQL API in minutes/hours, you just define the models. kind of the viewsets of Django Rest Framework. here are 2 examples both free as of now
Hasura.io you define the models in a GUI and you have in an instant an GraphQL with authentication permissions etc. You don't have access to customize the code but you can add your custom "end points" with remote schema.
Amplication.com generates for you a NestJS backend with Prisma orm. In this case the is not a blackbox you get an auto generated code base, you can customize every endpoint(resolvers). For me any many others moving from Django to NestJS (do not confuse with Next or Nuxt ... i know ...) was very easy for me and many others, NestJS just like Django is very "battery included".
P.S. I know moving away from django doesn't feel that good but I cannot describe how good it feels to get a GraphQL API that fast.
If you have any questions let me know.
I have heard about hasura and amplication. For some reason thought amplication was built on top of nextjs..:)
Anyhow have already implemented graphql with nextjs and django today and it looks promising. Right now curiosity is the leading the way, but I def see where it can save time as you say.
Thanks!
in you are implementing in django and dont wanna try other backends i hope you use grapene as someone down here suggested
amplication.com is basically generating a Nest.js app ( do not confuse with nextjs or nuxt js .....i know these names )
you define your models and even that in a nice visual way and it generates a NestJS app app with GraphqQL api and a react-admin for admin interface. I have not seen such a fast way of developing a backend.
if you need some customization everything is there all the code is simple just jump in and customize it, like adding a computed field and so on.
There are tools such as this for Django as well, for example apibakery.com (disclaimer, I'm the founder).
I am on the edge about using GraphQL myself. At one point it seems like it would be an useful additional tool in my arsenal, then at the others it looks like a lot of extra complexity (compared to REST APIs that you get for free with DRF, for example).
So far I haven't taken the plunge.
cool stuff with apibakery.com !! congrats!
I am yet to find one experienced frontend dev that tried GraphQL for more than 3 months and says that GraphQL did not increase their productivity and simplicity of the code drastically.
now implementing that on the backend is extra complexity.
However if you get a GraphQL CRUD for free, with no effort why not use it? And by GraphQL CRUD I mean :
All this without writing a line of code in the backend just defining the models run some commands
Yep, my apps running OK with a very low band-width
If you are using Postgres, try Hasura. This exposes Postgres data in graphql format.
Less than 10% of projects needs graphic according to me. Lot of over head by using gql. Stick with good old REST
Definitely not.
I think separating the backend into an API and running a SPA (preferably SSR with Next/Nuxt type frameworks) app on it's own.
This makes the backend leaner and easier to scale.
You already know Django, perfect. Now try to learn DRF - Django REST Framework. It shouldn't be too hard for you. Then just connect your frontend to your backend API.
Working with Django templates while trying to create a modern app is probably not the fastest approach. It's fine for CMS style apps, but not for those with many user interactions.
Thanks. Can you explain the first sentence please? not sure I understand..
It's a good idea to separate the backend and frontend (as opposed to backend serving your frontend - via django templates). And that they communicate via an API (whether it's REST or GraphQL doesn't really matter).
This is better for scalability and also for speed of development.
Also, you can run just React or Vue or Angular app, but if the app is going to grow in size, and also for SEO purposes, it's good to have the frontend built with Next (React) or Nuxt (Vue), which is kind of similar to django templating, but much faster for development, once you grasp the state management concepts, etc..
But in the end, it depends on the type of product you're building.
I'm just talking from my SaaS app building experience.
Thanks, yes I thought that's what you meant after re reading it a couple of times.
I'm really liking what I see with GraphQL, and looking into Next. Sometimes you have to expand your work experience to move much faster.. thanks again.
This comment has been voted down. Click to show.