Should I ditch Django for GO or full stack Next.js

Hey guys.

I am a beginner and have been building a Nextjs + Django rest framework web app for a long time now.

I was asking for some help on a discord server and I was questioned why I have been using django, and told that its a bad idea, a pain in the ass, very complex, and other solutions are much better like Nextjs backend or GO.

I do agree django can be a pain in the ass, but should i really just ditch it and migrate to go?

MrSir•6/16/24, 6:14 PM

thing with nextjs is that it is already doing back end work, it seems like you are mounting 2 backend framworks on top of each over.

how are you excecuting that? isn`t nextjs good on its own for a simple rest?

you could get confused with react and next, next is a meta framework for react, it is both backend and frontend.

django is a python backend, it is very powerfull for large apps and has good admin dashboards and iternal database.

if you wish only to build a simple rest api using django is like shooting a fly with a tank,
Go is much thinner simpler and faster to configure in this case

MMrSir thing with nextjs is that it is already doing back end work, it seems like you a...

NahascoOP•6/16/24, 9:43 PM

I moved from react to nextjs because I liked how routing works in nextjs. It is simple and easy to work with. Thats the only reason I am using nextjs instead of react.

The application I am building is not that simple. It is a management system that will store, manipulate, and show alot of data.

I went with Django because it was what I learned in the course that got me into web development.

I did have some pain using it, more specifically type checking. Laos is having some very nice out if the box features I sometimes suffered from fully understanding whats exactly going on. Things just worked most of the time.

Some folks at a different server were incredibly negative about using Django and they shared and amplified my concerns with it.

Many suggested Go, aps.net, or any other backend but django or basically python.

I was honestly upset that if I decide to switch backends Ill have to spend tens of hours migrating to a new backend.

However if other backends are really a better fit for me and my project then I would put the effort and time in migrating.

Then I have the issue in deciding which backend I should migrate to.

I really am convinced Next.js backend isn't a good idea. Coupling frontend and backend isn't very advised in what I have read so far. And I like the idea of having separate frontend and backend. I like the flexibility and conveniance of being able to easily connect different frontends like a web app and mobile app to the same backend or the benefit of being able to change backend and frontends easily.

In this case what separate backends should I migrate to?

My first impression on Go is that its a language, not a web framework, and Ill have to write and learn shitload of code to make it work as a web framework.

I am just so confused and lost now and need some guidance.

NahascoOP•6/16/24, 9:45 PM

Things in Django that I take for granted like it taking care of the database and providing a admin backend. Like I fear such things would take me ages to implement in other backends like Go.

Femi O.•6/16/24, 11:46 PM

It is not worth switching to and learning an entirely new language just for a backend. Go is great but Python can fit in your project just fine. Also, you're going to run into very similar "I don't fully understand what's going on" problems, probably even more so as you switch languages

Femi O.•6/16/24, 11:47 PM

If you're just doing CRUD, I'd recommend sticking it out with Python. The fact that you're struggling rn is good, it's more important that you experience a hard time and learn from it.

Femi O.•6/16/24, 11:48 PM

With that said, if you're just using your backend for fetching data there's no reason why you can't use Nextjs' integrated server, or a more barebones Python BE framework like FastAPI or Django Ninja etc.

FFemi O.With that said, if you're just using your backend for fetching data there's no r...

NahascoOP•6/17/24, 1:37 AM

But I am not just fetching data, the backend processes data. It reads and writes. Frontend can add students, teachers, classes, edit them or delete them. This is mostly what the app will do.

Receive input from managers, teachers about students and their daily class. Information about what the student recites and reads will be recorded.

I will them use the data to present it in different ways throughout the frontend and also create analytics and pdf reports.

NahascoOP•6/17/24, 1:48 AM

Julienng•6/17/24, 2:33 PM

The real question is about what you are comfortable with

Nextjs can handle workload just fine as a backend service, but it works too with a separate backend, probably event easier for some specific use cases like backend processes, cron, etc.

There is no "you should do it that way", it is a tradeoff about your belief, what you like working with and, most importantly, the people you are working with on that project.

If you know Django for backend stuff, keep it. If you are not satisfied with Django, look for something else and create a simple POC.

I've built apps with Next.js only and apps with a separated backend because it was needed for the team I work in. Either works

JJulienng The real question is about what you are comfortable with Nextjs can handle work...

NahascoOP•6/17/24, 3:06 PM

I am a junior and I am not sure what I am comfortable with yet.

For now I have been using NextJS + Django rest framework

It works but I am starting not to like Django, especially when I migrated to typescript in next. Types are just so nice.

I just am wondering if other backends are a better fit for me and my project.

NahascoOP•6/17/24, 3:12 PM

Should I stay with Nextjs + Drf
or switch to Nextjs + Prisma or Nextjs + other backend

Julienng•6/17/24, 3:31 PM

If you are a junior, keep playing with language and framework. This is great for your understanding of the developer ecosystem and understand what you find interesting.

You have a lot of variety of languages and all of them will a have one or more web framework to build rest api:

Java with Spring
PHP with Laravel
Node.js with AdonisJs
Golang with something like Gin
etc

For your current project, this highly depends on the current state of the project (early on ?) or the importance of the project for your employer. If the project has already started, moving to another web framework will only slow development down and will not add any immediate value for the end user

JJulienng If you are a junior, keep playing with language and framework. This is great for...

NahascoOP•6/17/24, 3:40 PM

It is a personal project, yet it is big. I have been working on it for a while now and it has become quiet complicated. Migrating to anything will defienetly take a very long time to do. But I was thinking if Django as a rest api isnt a good solution then I better migrate now than later.

Learning a new language is not what I need either, it will make the migration process much harder and time consuming. I only know JS and Python.

Should I stay with Nextjs + Drf?

Or migrate to

Nextjs + Prisma
React + FastAPI + SQLAlchemy
React + Express + Prisma

Julienng•6/17/24, 4:07 PM

Django as a rest api isnt a good solution

The thing I'm trying to convey is that there is no "not a good solution". Many teams are building great product with Django

This is not a framework I like using, but yeah, this doesn't mean it is not a good solution.

If I had to choose:

next + prisma for my personal project: less context switching and I do not need a separate rest API (which means you need to take care of the breaking changes)
next + adonisjs for a personal project with a need to have a separate rest API (like a public API as part of the product offering)
next + another framework that the team is comfortable with (in my current position, we are using quarkus in Java)

The question you have to ask yourself then is what is most important to you, the project or the learning experience?

I know this looks like a not an answer, but this is because there is no good answer here

NNahasco It is a personal project, yet it is big. I have been working on it for a while n...

Wonderful-Ade•6/17/24, 8:53 PM

I have not seen any credible reason in this thread as to why you should drop django, is it currently blocking a necessary feature or making it painful to do the most basic thing? You would keep changing your stack if you let every framework criticism get to you. There are people who scoff at the thought of javascript for backend. While it's good to listen to people of more experience, I would say just continue with this, since it is a personal project, and this is the only way for you to test the waters safely.

I started a project using FastApi last year, and I kept questioning if I made the right choice, while I can't say with 100% certainty that I made the right choice, as of now, I have not had any reason to say FastApi is a bad choice, because it does what i want it to

Juraj98•6/18/24, 1:26 AM

Hey @Nahasco, I just read through this thread and figured I might just throw in my opinion. Tl;dr is, I think you should go with Next for both FE and BE.

Juraj98•6/18/24, 1:26 AM

Why Next?

While I generally agree with the “you can do anything with any language/framework” sentiment. But if you’re a junior, it can be tricky. You won’t know if something is not good or needlessly complicated if you never explore other options.

You said “I really am convinced Next.js backend isn't a good idea.” And… I kinda agree with this. But not for reasons you probably think.

Javascript is pretty bad language. Typescript makes it a lot better, but it’s still not as robust and performant as something like Go.

Next also has its shortcomings. First of all, if you write your BE in Next, you can only do serverless. This means that every api call spins up a temporary box that excuses your code and then destroys it. There is no (easy) way to do long running tasks as you can do on a classic server. Plus, deploying Next on anything that’s not Vercel can be painful. (Although it can be done.)

But despite all of this, a lot of people choose Next as their full-stack solution. Why? Because the power you get with coupling your FE and BE into one framework is unmatched. If you do it right, you get full type-safety automatically inferred across you application. This means, that if you change something, everything that depends on it will scream at you to make sure you don’t forget to update it too. This allows you to build incredibly fast.

You mentioned two points with regards to coupling FE and BE - Connection from other clients (Mobile app) and ease of swap each part.

For the first point, you can connect to your Next’s endpoints just like you connect to any other rest endpoints (unless you go with trpc, which I’ll mention later).

As for the swapability, I don’t think this is actually the case. It’s never easy to swap you “end”. If it was, you wouldn’t be asking for advice if you should ditch Django. You’d just easily do it.

Juraj98•6/18/24, 1:27 AM

Other options

Other meta-frameworks.

You have a lot of options that are not Next. SolidStart, SvelteKit, Remix, Nuxt. And… I actually think that’s it.

I think Next is still the best for you out of these options, simply because it’s the most popular. There is a lot of learning resources - articles, videos, courses. There is a huge selection of libraries that can make your work easier and the most of the useful ones have dedicated docs sections about Next. If you choose to use any third party providers, they also often have guides to integrate specifically with Next.

But of course, you could probably do what you need to do with any of the meta-frameworks.

React + Standalone BE

There are two options I’d consider here. Stick with Python or go with Go.

Sticking with Python would be just to save the time since that’s what you’re already using.

Go is simple and performant. It’s a solid language that can help you get a job you like

Juraj98•6/18/24, 1:27 AM

-
There are other options. (Almost) any language can be used to write a BE service, but I’ll address the ones there were mentioned here:

Typescript
- It’s simple, it’s the same language you’ll have to use on FE, and you can achieve pretty good type-safety even if you have FE and BE split. It’s also not really performant and has it quirks. If you’re going to go with typescript, why not go with meta-framework? Splitting it is just needless setup time.
Nest
- While Nest is technically Typescript, please don’t use Nest. It’s so bad, I had to separate it from Typescript. Nest took the verbosity of Angular and brought it Javascript. Even if you know JS/TS, you’ll have to learn Nest. While you’re learning you might feel like you are just not good enough, that once you improve it’ll get easier. And when you learn it all, you’ll know you want to switch.
Java, C#
- Meh. Sure it can be done, but will you be happy writing it?
Rust
- There are two types of developers who should write Rust. Developers who want to learn Rust, and developers who know they have good reason to write Rust.

Juraj98•6/18/24, 1:27 AM

Doing Next right

So, if you’re considering Next, there are many ways to do Next.

Endpoints

First question to ask is, are you going to be connecting to the BE from anything that’s not FE? You mentioned mobile, but I feel like you only mentioned it only as an example.

If it’s FE and BE only, look into trpc. It’s based on react-query, which is data loading and state management library. But with trpc, you write your BE procedures (imagine endpoints) and can call them from FE with fully inferred safety. This will drastically speed up you development and you have less of a chance to shoot yourself in the foot.

If you want to connect to the BE from anything that is not your Next’s FE, trpc might be tricky. Trpc only uses one endpoint that is uses to handle communication between your FE and trpc procedures. I believe you could still communicate through this trpc endpoint even from other clients, but I’ve never actually done it. Also I believe there are solutions to expose your trpc procedures as normal endpoints, but again, I have no actual experience with this.

Keep in mind, the front-end part of trpc is both for data loading and state management. I’ve seen way to often people using react-query only for data loading and than duplicating the state in another state management library. I think this would be more awkward to do with trpc, but I think it’s work pointing out.

Of course, don’t need to use trpc, and can use Next’s normal api endpoints. But it’ll be a lot more code to match the experience.

Juraj98•6/18/24, 1:27 AM

ORM

You mentioned Prisma. Try drizzle-orm instead. It’s the same experience as Prisma, but it has less quirks.

Third party providers

You haven’t talked about this, but there are few third party providers I think are worth mentioning.

If you need auth - Use Clerk. I’ve been using it and it’s been great. It’s super easy to integrate and they have great docs.

If you need file upload - Use UploadThing. Tbh, I don’t know alternatives. But I do know that doing file uploads to something like S3 has been painful. UploadThing can save you from shooting yourself in the foot.

If you need realtime - Use Supabase. It’s easy to setup, has great docs, and it best pricing by far. I looked at other solely websocket providers and they are lot pricier.

It’s worth mentioning that if you go with Supabase, they do also have auth and file upload solution. I haven’t used them, so no strong opinions.

Infra

If you’re using Next, you’ll probably want to deploy it to Vercel. As I mentioned earlier, it’s possible to deploy Next to self hosted server, but it can be painful. I’d recommend try to avoid that headache, or at least delay it for as long as you can.
Vercel also offers PostreSQL db hosting, which might be useful for you. It’s technically run thorough Neon.tech, but that can be advantageous. There is one free DB instance per account on both Vercel and on Neon. If you want to be fancy, you could use one of these free instances for you dev environment, and one for your production environment.

create-t3-app

If you don’t already know, there is create-t3-app. It can help you get started with next + trpc + drizzle-orm in fully typesafe way.

Juraj98•6/18/24, 1:27 AM

Honorable mentions

You mentioned you only used Next because you like routing. If you stick with Django, look into @tanstack/router. You can achieve everything you can with next router, plus a lot more. If routing is the only reason you’re using Next, it’s probably not worth it.

NahascoOP•6/18/24, 8:20 AM

Thank you for the great input @Juraj98 , I am convinced the t3 stack is the most productive and easiest to manage when solo working on a project, although it has its drawbacks. I will for sure give it a shot in my next projects.

But I am not sure if I should do it for my current project. The issue is that I see this project as a long term one and I wont stop working on it anytime soon. I am slowly leaning towards sticking with Django, maybe switching to Django ninja but with no certainty. I can't decide if it's worth it.

Should I ditch Django for GO or full stack Next.js

Why Next?

Other options

Other meta-frameworks.

React + Standalone BE

Doing Next right

Endpoints

ORM

Third party providers

Infra

create-t3-app

Honorable mentions

Similar Threads

Similar Threads

Why Next?

Other options

Other meta-frameworks.

React + Standalone BE

Doing Next right

Endpoints

ORM

Third party providers

Infra

create-t3-app

Honorable mentions

Similar Threads