Anyone builds with Next.js + Django/Laravel/Rails?
Hello solo hackers,
Over the years I have built a lot of expertise in Next.js/React and Django.
What I don't like is finding myself creating the glue code that make them both stick together: the API, the views, the serializers, the queries, the mutations. It's all a headache for all the complexity it adds.
It's all supposed to make it more decoupled and maintainable, but to make something maintainable nothing beats less code, and having everything is one project is definitely less code.
So my questions to you are:
- how do you do it?
- am I the only one experiencing this pain?
- did you find the formula that make it comfortable for you?
Thank you friends for you answers
You are not crazy, and there is a better way.
There's a library called StimulusReflex which has taken the Rails world by storm over the past year. It allows you to create reactive apps with fully server-side state. User events are captured and relayed to the server, state mutations are persisted and only the changes are sent back to the client in a few ms.
Everything is done over WebSockets. There's no API, no JSON payloads, no routing, no virtual DOM. You're just morphing changes to the DOM faster than the eye can perceive.
What we've realized is that maintaining state on the client and server and then trying to keep them in sync is like 80% of the pain when you're building a web app. When you see that you can just say no to that complexity, it's an incredible feeling.
https://alistapart.com/article/the-future-of-web-software-is-html-over-websockets/
https://obie.medium.com/react-is-dead-long-live-reactive-rails-long-live-stimulusreflex-and-viewcomponent-cd061e2b0fe2
https://www.youtube.com/watch?v=F5hA79vKE_E
Thanks for kind words.
It's an indescribably good feeling indeed not to have to write and maintain client/server state.
Wow, I had no idea StimulusReflex was that big. I completely forgot about it. Does it compare to the newer hotwire.dev?
StimulusReflex and CableReady eclipse Hotwire/Turbo in every meaningful way. While Turbo is good for simple cases, you tend to hit the ceiling pretty fast. Still, it could be good enough for developers who aren't building anything more sophisticated than form submissions. Think of Turbo as the evolution of UJS, if that means anything to you.
I don't use Next.js, but I do use Svelte + Rails API.
Honestly, I don't find it extra complex. In Rails proper, I'll still have an API, still have views, serializers and queries.
In fact, I LOVE having it be separate apps now, as it's extremely clear what's in my API and being consumed. As I define out my mobile app (Flutter) it's easy to extend/understand my API as a separate bit.
I was/am still incredibly productive in Rails only, but since having switched, I'm probably a little bit more productive using Svelte and my frontends have never been nicer/faster/etc.
that's nice to hear! I can tell there are many people who aren't bothered with writing and maintaining APIs. Of course if you have a mobile app, there is absolutely no choice, but it seems people also enjoy the separation.
I've gotten to like the monolith since I'm building solo projects. My first solo projects had at least 2 repos covering the front end and back end. I've already stopped that a while ago with monorepo, but now I'm looking into removing even more layers of separations.
I'm using next.js for the frontend and Django for the backend. I actually really like Django rest framework in that it provides a lot of stuff out of the box and you don't have to write much code but still very customizable. Similar with next.
I think it mostly depends on how complex your project is or is going to be to justify not having just one project. The good thing about Django and next is that it can pretty much handle anything and maybe if you have something like lots of asynchronous jobs that are typically handled with python tools that's a good way to go.
Also having front and back end separate makes it easier for multiple people to work on either.
Generally you probably want to keep all that complexity in check with proper automated testing which (suprise) is also pretty complex if you truly want to test the entire application and not just backend and frontend separately.
So yeah only go the complex route if you have to and use the tools you're most familiar with would be my advice.
I agree it's simpler to work with when you have a team, each with their own expertise, but I'm usually solo.
I think I wish Django could render React, which I can later rehydrate. I would then use it like Next.js, except I don't need to throw away class based views
DRF is really good for making APIs, but it gets messy as soon as you start handling mutations with nested relations. I've tried graphene as well, same mess, hardly DRY. Working with class bases views almost always results in less code IMHO.