Stop Deploying Frontend and Backend Separately: Let Your Backend Serve the Frontend

Most of us follow a common project structure:

frontend/   → React / Angular / Vue  
backend/    → Node / Java / Python

We deploy:

  • Frontend to Netlify, Vercel, or S3
  • Backend to EC2, Heroku, or some server

This works, but it also adds extra complexity:

  • Two deployments
  • CORS issues
  • Separate domains and SSL configs
  • More infrastructure to manage

Recently, I came across a simpler and cleaner approach —
deploy only the backend, and let it serve the frontend as well.

And honestly… it’s an awesome concept.

What Does “Backend Serves Frontend” Mean?

In this approach:

  • You still develop frontend and backend separately
  • But during deployment, the backend serves the frontend’s built files

So instead of hosting two applications, you host only one server.

That server:

  • Serves API endpoints (/api/*)
  • Serves frontend UI (/)

How It Works (High Level)

1. Build the Frontend

Frontend frameworks like React, Vue, or Angular produce static files:

index.html
main.js
assets/

This is done using:

npm run build

2. Backend Serves the Built Files

The backend is configured to:

  • Serve these static files
  • Handle API requests

So:

  • https://myapp.com → Frontend UI
  • https://myapp.com/api/users → Backend API

All from one server.

Typical Project Structure

project/
├── frontend/
│   └── React / Vue / Angular source
├── backend/
│   ├── server code
│   └── build/   ← frontend build output

Or a monorepo style:

project/
├── client/
├── server/
└── package.json

Why This Approach Is So Powerful

✅ Only One Deployment

No need to deploy frontend and backend separately.

✅ No CORS Problems

Frontend and backend share the same origin.

✅ Simplified Infrastructure

One server, one domain, one SSL certificate.

✅ Faster Development for Small Teams

Less DevOps overhead, fewer moving parts.

Is This a New Concept?

Not really.

Before modern SPAs:

  • JSP
  • Thymeleaf
  • PHP
  • ASP.NET

Backends always served the UI.

Modern tools just brought this idea back — but with React, Vue, and Angular.

Frameworks like:

  • Next.js
  • Nuxt
  • Spring Boot
  • Django

All support this pattern naturally.

When Should You Use This?

Best Use Cases

  • MVPs
  • Small to medium applications
  • Internal tools
  • Early-stage startups

When to Avoid

  • Extremely high frontend traffic
  • Frontend and backend need independent scaling
  • Multiple frontend apps using the same backend

Final Thoughts

If your frontend is ultimately just static files, there’s no strict need to host it separately.

Letting your backend serve the frontend:

  • Reduces complexity
  • Avoids unnecessary infrastructure
  • Makes deployments cleaner and faster

Sometimes, the simplest architecture is the best one.

Happy Learning 🚀

Comments

Post a Comment

Popular posts from this blog

How to enable Google Sheet in Google Cloud project

Image
 Hi, In this post, we will see how to enable Google sheet APis in Google Cloud project. Go to Google Cloud Console: Visit: https://console.cloud.google.com/ Make sure you're in your project Navigate to APIs & Services: Go to "APIs & Services" > "Library" (or use the search) Enable Google Sheets API: Search for "Google Sheets API" Click on it Click "Enable" Wait a few minutes: After enabling, wait 1–2 minutes for the change to propagate. Thank you.
Read more

Finding Your Redis Credentials: Host, Port, and Password

 Finding Your Redis Credentials: Host, Port, and Password Here is how to hunt down your Redis credentials in seconds. 1. The Host: Where is Redis living? In 90% of local development scenarios (including WSL), Redis lives right on your machine. Standard Local Host: 127.0.0.1 or localhost Remote Server: If you're connecting to a staging or production server, you will need that server's specific IP address or domain name (e.g., redis.example.com ). 2. The Port: Which door is open? The default port for Redis is 6379 . However, if you're running multiple instances, it might be different. To confirm exactly which port your instance is listening on, run: redis-cli CONFIG GET port Alternatively, you can ask your system which process is "squatting" on the network: sudo ss -tlnp | grep redis If you see 0.0.0.0:6379 , you're using the default. 3. The Password: Is the gate locked? By default, a fresh Redis installation has no password . In a local environment, this is ...
Read more

Ways to install your own extension

 In visual studio  Extension Manager ,  shows extensions from the Marketplace. But you can install your own .vsix extension manually — here’s how: 🛠️ Ways to install your own extension Double‑click the VSIX file : After you build your extension project, Visual Studio produces a .vsix file. Just double‑click it, and the Visual Studio Installer will open to install it. Use the Experimental Instance : When debugging your extension, Visual Studio launches a special “Experimental Instance” where your extension is auto‑installed for testing. Command line install : You can use VSIXInstaller.exe (included with Visual Studio) to install your extension manually. Example:                          VSIXInstaller.exe MyExtension.vsix Local install via Extensions menu : In newer Visual Studio versions, go to Extensions → Manage Extensions → Install from VSIX… and select your file.
Read more