Puskar Adhikari

Puskar Adhikari Software engineer

Software is built in layers. I work on all of them.

I build reliable products across interfaces, architecture, and infrastructure, from the first screen to the pipeline that ships it.

Explore how I work GitHub LinkedIn

What people see and touch. React, Next.js, React Native, TypeScript, Astro

Services, APIs, and the rules in between. Node.js, Bun, Laravel, FastAPI, Auth0

Where it runs and what it remembers. Docker, Kubernetes, AWS, Azure, PostgreSQL

Inside:
Inside:
Inside:

Engineering, end to end

Five disciplines that only work well together. Pick one to see where it meets the others.

Architecture

Shaping systems so teams can change them safely.

  • Frontend Rendering strategy is chosen per route.
  • Backend Service boundaries follow the domain.
  • Infrastructure Designs fit how the system is deployed.
  • Security Trust boundaries are drawn up front.

Microservices · Monorepos · Event-driven workflows

Frontend

Fast, accessible interfaces built from shared parts.

  • Architecture Rendering strategy is chosen per route.
  • Backend Typed API contracts, agreed before either side is built.
  • Infrastructure One image, runtime config per environment.

React · Next.js · React Native · TypeScript

Backend

APIs and services that frontends can rely on.

  • Architecture Service boundaries follow the domain.
  • Frontend Typed API contracts, agreed before either side is built.
  • Security Roles are checked at the boundary and logged.

Node.js · Bun · Laravel · PostgreSQL

Infrastructure

Build once, promote everywhere, scale on demand.

  • Architecture Designs fit how the system is deployed.
  • Security Secrets stay out of images and pipelines.
  • Frontend One image, runtime config per environment.

Docker · Kubernetes · AWS · GitHub Actions

Security

The secure path made the easy one.

  • Architecture Trust boundaries are drawn up front.
  • Backend Roles are checked at the boundary and logged.
  • Infrastructure Secrets stay out of images and pipelines.

OpenID Connect · PKCE · RBAC · Audit logs

The full toolset

Engineering Lab

Ideas, experiments, and engineering decisions in practice.

Where should a page render?

The same page, delivered three ways. Pick a strategy, then change the network and the API speed.

Strategy

Server-side rendering

HTML is built on the server for every request, next to the API.

Fresh data on every request and content early, but the server waits on the API first, and the page can look ready before it responds.

Content at 750 ms, responds at 1.9 s

requestdataBrowserCDNServerAPI
Network
  1. Client-side rendering

    Content 1.9 s, responds 1.9 s

  2. Server-side rendering

    Content 750 ms, responds 1.9 s

  3. Static generation

    Content 420 ms, responds 680 ms

A teaching model, not a measurement: 170 KB app bundle, 18 KB of islands for the static page, one round trip to connect, no caching. Real systems mix strategies per route.

SSR and CSR at scale, in practice

Writing and experiments

Articles

  1. Docker for Next.js: A Practical Production Guide 5 min read
  2. Generate Dynamic Open Graph Images Using Satori 8 min read
  3. Tree Shaking in JavaScript: Cut the Code, Keep the Speed 4 min read

All articles

Open source and lab

Projects I've worked on

Healthcare, ERP, education, and marketplace products, from early builds to platforms in daily use.

Details and open source

Have a product to build or a system to untangle?

I read every message. Roles, collaborations, or a question about something I wrote — email works best, or use the form.