DEV Community: Sanket Jagtap

Deploying a Full-Stack App with Docker and Nginx on a VPS

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

You do not need Kubernetes to ship a real app. A single VPS with Nginx and Docker handles a surprising amount of traffic. Here is the setup that runs this portfolio.

The topology

Nginx is the front door, terminating SSL and serving the built Angular app as static files.
The Node + Prisma API runs in a Docker container on a private port (6000).
MySQL is the database; uploaded images live on a persistent host volume.

Nginx as the front door

One server block does three jobs: serve the SPA with a history-API fallback, reverse-proxy the API, and serve uploaded files. The detail that bites everyone is the trailing slash on proxy_pass :

location /api/ {
  proxy_pass http://localhost:6000; # no trailing slash -> keeps /api prefix
}
location / {
  try_files $uri $uri/ /index.html; # SPA fallback
}

With a trailing slash Nginx strips the matched prefix, so /api/users would arrive at the backend as /users and 404. Dropping the slash preserves the path.

Persistent uploads

Anything written inside a container is gone on the next deploy. Uploads must live on the host and be mounted in, with ownership that matches the container user:

docker run -d --restart unless-stopped \
  -p 6000:6000 --env-file .env \
  -v /opt/app/uploads:/opt/app/uploads \
  portfolio

SSL

Let's Encrypt via certbot gives free, auto-renewing certificates. Nginx redirects all HTTP to HTTPS, so the app is TLS-only.

Deploys

The flow is pleasantly boring: pull the latest code, docker build , stop the old container, run the new one. Because migrations run on startup and uploads live outside the container, a redeploy is safe and repeatable.

Gotchas worth remembering

proxy_pass trailing slash changes the forwarded path — choose deliberately.
A non-root container user cannot write to a root-owned host volume; fix the ownership.
An existing database needs its migrations baselined once (P3005) before migrate deploy will run.

Making a Node.js and Prisma API Production-Ready

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

"It works on my machine" and "it is production-ready" are very different statements. Here is the checklist I worked through to take an Express + Prisma + MySQL API from the first to the second — using this very portfolio backend as the guinea pig.

1. Real migrations, not db push

prisma db push is great for prototyping and dangerous in production — there is no history and no safe rollback. The fix is committed migrations applied on deploy:

npx prisma migrate dev --name init # generate + commit
npx prisma migrate deploy # run on startup (never prompts)

If the database already has tables but no migration history you will hit P3005. Baseline it once by marking the migration as already applied, then deploys are clean forever after.

2. Graceful shutdown

Containers get SIGTERM on every redeploy. Without handling it you drop in-flight requests and leak database connections. Close the server, then disconnect Prisma:

process.on('SIGTERM', async () => {
  server.close(async () => {
    await prisma.$disconnect();
    process.exit(0);
  });
});

3. Map errors to real status codes

A blanket 500 tells the client nothing. A small helper maps known Prisma errors — unique violation to 409 , record-not-found to 404 — and keeps the raw error server-side only.

4. Liveness vs readiness

Two different questions. /health answers "is the process up?" cheaply. /health/ready answers "can I serve traffic?" by actually pinging the database with SELECT 1 — that is what your load balancer should probe.

5. Config and secrets

Fail fast at startup if a required secret like JWT_SECRET is missing.
Never ship a hardcoded admin password — seed a random one and print it once.
Keep .env out of git; commit a .env.example template instead.

6. A lean Docker image

A multi-stage build compiles TypeScript in a builder stage and ships only the runtime deps and compiled output, running as a non-root user. Migrations run as the first thing the container does on boot.

None of this is exciting, and that is the point. Production-ready means boring, predictable and observable.

Inside AlgoETF: An Algorithmic ETF Trading Platform

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

AlgoETF is an algorithmic trading platform for Indian ETFs. It runs rule-based strategies against live market data, places orders through connected brokers, and lets you research everything with a built-in backtester before risking real money.

The core strategy

At its heart is a simple, explainable idea: buy the dip, sell the rise , gated by momentum. The engine watches each ETF and acts when price moves a configured percentage, but only when the RSI(14) filter agrees — so it avoids buying into a falling knife or selling into strength.

Buy on dip and sell on rise thresholds, per ETF.
RSI oversold / overbought gate to filter bad entries.
Cycle targets so each position has a defined exit.

Real-time architecture

The frontend is Angular; the backend is Node.js + Express. Live prices and order updates stream over WebSockets , Redis handles pub/sub and hot state, and MySQL is the system of record for strategies, cycles and orders. Broker APIs sit behind an adapter layer so new brokers can be added without touching the strategy code.

The backtester

You can replay historical 1-minute data through the exact same strategy logic — research only, no orders placed. The best part is the A/B improvement rules : toggle a stop-loss, cap averaging, an EMA trend filter, a volume filter or a trailing exit, and compare the result against the base strategy.

Parameters: stock, date range, buy dip %, sell rise %
Gate: RSI period, oversold <, overbought >
Risk: qty/order, start capital, brokerage %, slippage %
A/B rules: stop loss, cap averaging, EMA filter, trailing exit

Safety first

Trading code is unforgiving, so the platform separates live , paper and backtest modes explicitly. Paper trading mirrors live behaviour with no money at stake, and every order is logged with a clear success / pending / failed status.

Lessons learned

Make strategies boring and explainable — you have to trust them with money.
Backtesting and live execution must share the same code path, or your results lie.
An audit trail of every order is not optional in fintech.

Building BeatNest: A Cross-Platform Music App in Flutter

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

BeatNest is a cross-platform music streaming app built with Flutter. It streams tracks from the Saavn API and focuses on the things that actually make a music player feel good: gapless background playback , media-style notifications, lock-screen controls and offline listening.

Why Flutter

One codebase, two stores. Flutter let me ship a consistent UI on Android and iOS while still dropping down to native APIs where it mattered — the media session, notifications and storage permissions.

Architecture

The app follows a clean, service-oriented structure so the UI stays dumb and the logic stays testable:

ApiService — talks to the Saavn API for search and trending songs.
MusicService — the playback brain: queue, current track, play/pause/seek, exposed as reactive streams with rxdart.
AudioHandler — the background audio service that survives the app being backgrounded.

Background playback

This is where most music apps fall apart. BeatNest combines just_audio for the player with audio_service for the OS-level media session. That gives you a notification with controls, lock-screen artwork, and playback that keeps going when the app is swiped away.

dependencies:
  just_audio: ^0.10.5
  audio_service: ^0.18.12
  audio_session: ^0.2.3
  rxdart: ^0.28.0

Auth and cloud sync

Users can continue as a guest or sign in with email or Google via Firebase Auth. Signing in syncs their liked songs and playlists across devices through Cloud Firestore, so the library follows the user, not the phone.

Offline and resilience

Downloads use dio with a local SQLite index so songs are available without a connection, and connectivity_plus gracefully degrades the UI when the network drops. Crashes and usage are tracked with Firebase Crashlytics and Analytics.

Lessons learned

Treat the audio session as the source of truth — the UI should reflect it, never drive it directly.
Background execution rules differ a lot between Android and iOS; test on real devices early.
A "Continue as guest" path removes friction and still lets you upsell sync later.

BeatNest started as an experiment in "can Flutter really do a proper media app?" The answer turned out to be a confident yes.

Angular Beyond the Docs: What 4+ Years of Production Code Taught Me

Sanket Jagtap — Wed, 17 Jun 2026 16:54:24 +0000

Angular Beyond the Docs: What 4+ Years of Production Code Taught Me

Most Angular blogs explain what a feature does.

Very few talk about when it hurts, when it helps, and when not to use it.

After more than 4 years of building Angular applications in production , I’ve learned that the hardest problems were never about syntax or APIs — they were about decisions.

This post is for developers who already know Angular and want to think more clearly while building real systems.

The Real Problem Was Never Angular — It Was Over-Abstraction

Early in my career, I believed:

More architecture means better code.

So I built:

1. Deep folder hierarchies
2. Over-generic services
“Shared” modules that depended on everything
Reusable components that were rarely reused

The result wasn’t scalability — it was:

Slower development
Harder onboarding
Fear of touching existing code

Modern Angular didn’t just introduce new features — it removed the need for unnecessary structure.

Lesson:

Simplicity scales better than cleverness.

Signals Didn’t Replace RxJS — They Replaced Misuse of RxJS

Signals are often described as “Angular without RxJS.”

That’s not accurate.

RxJS was never the real problem.

Using RxJS for synchronous UI state was.

What went wrong in real projects:

Observables for button state
Subscriptions inside components
Boilerplate like takeUntil(destroy$) everywhere
UI bugs caused by async timing

What signals fixed:

UI state became synchronous again
No subscriptions
No memory-leak anxiety
Predictable rendering

Lesson:

Signals didn’t replace RxJS — they rescued it from being overused.

Today my rule is simple:

Signals → UI and local state
RxJS → async streams (HTTP, WebSockets)

Change Detection Wasn’t Slow — Our Mental Model Was

For years, Angular performance advice felt like magic spells:

Use OnPush
Add trackBy
Avoid functions in templates

We followed rules without understanding why.

Signals changed this by making change detection explicit :

Angular updates only what reads a signal
Not the whole component tree
Not “everything just in case”

Lesson:

Performance improves when the framework matches how developers think.

Standalone Components Solved a Human Problem

NgModules worked — but they created cognitive overhead :

Where is this provided?
Why is this imported here?
Which module owns this component?

Standalone components didn’t just reduce code.

They reduced questions.

Developers can now open a file and understand it without tracing imports across multiple modules.

Lesson:

The best abstractions are the ones you don’t have to explain.

State Management Is a Cost — Not a Feature

NgRx is powerful.

It’s also expensive.

In production, I’ve seen:

Simple apps buried under actions and reducers
Teams afraid to touch state logic
Bugs hidden behind boilerplate

Signals enabled something important:

Local state that stays local.

My approach today:

Start with signals
Introduce heavier state management only when complexity demands it

Lesson:

State management should grow with the problem — not ahead of it.

The Biggest Angular Upgrade Is Restraint

Modern Angular gives us:

Signals
Standalone APIs
Deferrable views
Better performance tools

But the real upgrade isn’t knowing more APIs.

It’s knowing when not to use them.

I now ask:

Does this abstraction reduce thinking?
Will this still make sense in two years?
Can someone else debug this easily?

Lesson:

Senior Angular development is about clarity, not cleverness.

Final Thoughts

Angular today is:

Faster
Simpler
More predictable

But frameworks don’t make applications maintainable — decisions do.

The best code is the one that survives change — not the one that impresses today.