<h1>Problem</h1>
<p>I’ve been working on a large-scale project for 7 months using Next.js and Postgres. As the team grew, I realized Next.js wasn’t performing well. Rendering during development became very slow, and since both backend and frontend developers had access to the full codebase, it made things harder to manage and understand. Setting up and testing the CI/CD pipeline was also challenging, and with Next.js 14, <a href="http://Socket.io" target="_blank" rel="noopener nofollow">Socket.io</a> is no longer supported due to server-side rendering (SSR).</p>
<h1>Solution</h1>
<p>To fix this, I decided to split the project: I put the backend in a separate folder and kept Next.js for the frontend. This helped solve most of the issues, but rendering during development is still slow.</p>
<p><strong>☺️Would love to hear your thoughts on this.</strong></p>


groCTO 

The author describes the struggles faced while working on a large-scale project using Next.js and Postgres. Major issues included slow rendering during development and challenges managing the full codebase with both backend and frontend developers. Additionally, setting up the CI/CD pipeline was difficult, and Next.js 14's lack of support for Socket.io due to server-side rendering (SSR) limitations posed problems. The author mitigated some issues by splitting the backend and frontend but still faces slow development rendering.

Why Next js failed for me...

<p>I shifted to just react + vite last year, never went back… I have a brain to keep healthy :)</p>


<p>I used to love Next.js but since v13 came out it became nonsense to me. I replaced it with Remix.</p>


<p>My team will switch to React + Vite, Next.js is causing so many problems that we’ve decided to switch…</p>


<p>too much is going on in Next tbh, I like simple CRA app with libraries like React Query, Context API and React Router.</p>


<p>Definitely agreeing with some of the comments here. I use Next quite a lot in the organisation I work for however we treat it as purely front end presentation to our back end APIs that are usually written in different tech stack. We’ve also taken the approach of micro front ends, that serve small purposes, creating BFFs, and having as minimal amount of code in the front end to off load to the back end services. But in all honesty, at that point you may as well just stick with react and a few libraries you may need. We’ve teams that split front end vs back end work, different teams using different tech stacks, different responsibilities, etc, so this works for us.</p>
