Stop 10 · Full-Stack FrameworksTopics · 7/7

Choosing a Full-Stack Framework

Part of the Full Stack Developer Roadmap

In short

One Next.js app, or a React frontend plus a separate Express API? Both work. The right pick depends on who calls your backend, how your team splits work and where you deploy.

Deciding between a meta-framework (Next.js/Remix) versus a separate React frontend plus Express backend — a real architectural decision with trade-offs in simplicity, deployment, and team structure.

The blob character stands thinking between a home stove with pots and a mess counter with a steel tray.

Think of it like this

Mess food or your own kitchen

The hostel mess is quick: the menu is fixed, plates are washed, no shopping needed. Cooking in your own flat takes more effort, but you choose every spice. A meta-framework like Next.js is the mess. A separate React app plus Express API is your own kitchen.

Watch it happen

One app or two?

Meta-framework

One repo, one deploy, shared types
Server rendering and data loading built in
Backend follows the framework's rules

React + Express

Frontend and API deploy separately
Any client can use the same API
More setup: CORS, two hosts, two pipelines

Small team with a web-only product? Start with a meta-framework. Mobile apps, other teams or heavy background work? A separate API pays off.

The big ideas

What you need to know

Who calls the backend?

If only your website does, one framework is simplest. If a mobile app or partners need it, a standalone API is cleaner.

SEO and first load

Public, searchable pages benefit from server rendering. Dashboards behind a login care much less.

Long-running work

Websockets, queues and cron jobs fit a long-running Node server better than short-lived serverless functions.

What your team knows

A stack your team already understands beats a trendy one. Learning time is a real cost.

How it works

A quick decision path

1
List your clients
Write down everything that will call your backend: website, mobile app, other services.
2
Check your pages
Mark which pages need SEO or a fast first load, and which sit behind a login.
3
Check background work
Note anything long-running: websockets, queues, scheduled jobs, heavy file processing.
4
Pick and start small
Choose the simplest setup that covers the list. You can split out an API later.

See it in code

Walk through the code

bash

1# Option A: one Next.js app (UI and backend together)2npx create-next-app@latest myshop3 4# Option B: separate frontend and API5npm create vite@latest web -- --template react-ts6mkdir api && cd api && npm init -y7npm install express cors8npm install -D typescript tsx @types/express @types/cors

1/3One command and you have pages, route handlers and server actions in a single project.

Option A gives you one folder, one dev server and one deploy. Option B gives you two of each, plus full freedom on the API side.

Save yourself the pain

Common mistakes

Oops

Choosing microservices for a college project whose only user is you.

Do this instead

Start with one app. Split it only when a real need appears, like a second client or a heavy background job.

Oops

Assuming a Next.js backend can't serve a mobile app.

Do this instead

Route handlers are plain HTTP endpoints. A mobile app can call them, as long as you design them like a proper API.

Your mission

Decide for your next project

~20 min

Quick check

Your startup has a web app and launches an Android app next month that needs the same data. Which setup fits best?

Go deeper

1List the trade-offs: a unified framework is simpler to deploy but couples frontend/backend releases together.
2Consider when a separate frontend/backend makes sense, e.g. a mobile app also needs to consume the same API.
3Recognize most modern full-stack projects default to Next.js unless there's a specific reason not to.