Technology · Node.js · PostgreSQL

Node.js back-end development
APIs, real-time and background jobs.

Node.js runs JavaScript and TypeScript on the server. It is well suited to what most product back ends spend their time doing: receiving requests, talking to a database and other services, and sending responses, for many users at once. Paired with PostgreSQL it is BBR’s default back end. For some workloads another runtime is the better choice, and this page says which.

Discuss your back end ↗

What we build with it

The server side
of web and mobile products.

Node.js uses an event-driven, non-blocking model: while one request waits for the database, the process serves others. That matches the shape of most application back ends.

APIs

REST or GraphQL APIs for web and mobile clients, with input validation, authentication, role-based authorization, rate limiting, versioning and generated documentation.

Real-time features

Chat, live dashboards, presence, notifications and collaborative updates over WebSockets or server-sent events. Long-lived connections are a workload Node.js handles comfortably.

Job queues and scheduled work

Emails, report generation, imports, webhooks and third-party sync moved out of the request path into a queue (typically Redis-backed) with retries, backoff and failure alerts.

Integrations

Payments, identity, messaging, maps, accounting and other external systems, wrapped so that their outages and quirks do not leak into your product. See API integration.

How BBR uses it

Default back end, conventional setup.

Node.js and PostgreSQL are part of BBR’s core stack, together with TypeScript, Docker and deployment to a client’s own VPS or cloud account. For products where a managed backend is enough, we use Supabase or Firebase instead of writing a server from scratch. Payment work covers Stripe-style payment integrations and store billing for apps.

We do not claim experience we cannot show. BBR does not train machine-learning models, does not offer Python, Go, Java or .NET teams, and holds no compliance certifications. What we can describe is how we set a Node.js project up, which is deliberately unexciting:

TypeScript in strict mode, with request and response schemas validated at the boundary and shared with the React / Next.js or React Native client
A well-structured monolith rather than microservices, until there is a measured reason to split
PostgreSQL with migrations in version control, constraints in the database and transactions around anything involving money or state changes
Background work in a queue, never inside a request that a user is waiting on
Automated tests on business rules and critical endpoints, run on every change
Structured logs, error tracking and health checks, so problems are visible before users report them
Secrets outside the repository, least-privilege database users, and dependency updates as routine maintenance
Docker images that run the same way on a laptop, on staging and in production

Fit

When Node.js is the right back end,
and when another runtime is.

Node.js is strong when the server mostly waits on other things. It is weaker when the server itself has to compute hard for a long time.

Good fit

Node.js suits the project if

The back end is an API over a database with integrations: most SaaS products, marketplaces, mobile app back ends and internal tools
It needs real-time features with many open connections
The front end is React, Next.js or React Native and you want one language, shared types and engineers who can work on both sides
It calls hosted AI model APIs and streams responses to clients
You want a very large package ecosystem and hiring pool

Not a fit

Another runtime is better if

The core work is CPU-heavy: video or image processing at volume, scientific computing, large in-memory data crunching. Go, Rust, Java or C# handle this more naturally
You are training or serving your own machine-learning models: the tooling lives in Python
Your organization is standardized on Java or .NET with teams and infrastructure to match
You need the lowest possible latency with tight memory control, as in trading systems or game servers at scale
The product is a CRUD application and your team already knows Rails, Laravel or Django well; their conventions will get you there faster

Alternatives

How it compares.

Runtime	Strength	Trade-off	Typical best use
Node.js (TypeScript)	I/O concurrency, real-time, one language with the front end, huge ecosystem	CPU-bound work blocks the event loop unless moved to workers or another service; dependency sprawl needs discipline	Product APIs, real-time features, integration-heavy back ends
Python (Django, FastAPI)	Data science and ML libraries; very readable; Django’s built-in admin	Generally slower per request; a second language alongside a JavaScript front end	Data- and ML-centered products
Go	Fast, low memory use, simple concurrency, single-binary deployment	More code for ordinary web features; smaller web ecosystem	High-throughput services and infrastructure
Java / Kotlin, C# / .NET	Mature, performant, strong tooling; standard in large enterprises	Heavier setup; slower for a small team to start with	Large enterprise systems
Ruby on Rails, Laravel (PHP)	Very quick CRUD development through convention	Less suited to real-time and high-concurrency work; separate language from the front end	Content- and form-heavy applications
Managed backend (Supabase, Firebase)	Auth, database, storage and real-time without writing a server	Complex business logic and unusual integrations outgrow it; pricing and limits are the vendor’s	MVPs and apps with simple server logic

Runtimes can be mixed. A common pattern is a Node.js API for the product with a separate worker in another language for one heavy task, connected through a queue. That is often better than choosing the whole stack around its most unusual requirement.

For how the back end fits into the rest of a product, see our guides to SaaS architecture and stack choices and picking a stack for a first release, or the web application and SaaS development service pages.

Questions

Frequently asked
questions.

Does Node.js scale?

For the I/O-bound work that makes up most web back ends, yes. A single process handles many concurrent connections, and you scale further by running more processes or containers behind a load balancer. In practice the database becomes the bottleneck long before the runtime does, which is why schema design, indexes and query patterns deserve more attention than the choice of language.

Which Node.js framework do you use?

It depends on the project. A minimal framework such as Express or Fastify suits small and medium APIs where a clear, conventional structure is enough. NestJS suits larger codebases that benefit from enforced structure. When the front end is Next.js and the server needs are light, its built-in route handlers may be all that is required. We choose the least machinery that fits.

Why PostgreSQL rather than MongoDB?

Most business data is relational: users belong to organizations, orders contain items, invoices reference customers. PostgreSQL enforces those relationships and gives you transactions, constraints and flexible querying, and its JSON columns cover the cases where a document shape is convenient. A document database is a reasonable choice for some workloads, but for a typical SaaS or app back end PostgreSQL is the lower-risk default.

Can you take over or extend an existing Node.js back end?

Yes. BBR can join or take over existing codebases. We begin with a short review of the code, dependencies, tests, deployment and database, and share what we find before quoting.

Do you build back ends in Python, Go, Java or .NET?

No. BBR’s back-end work is in Node.js with TypeScript. If your workload is a better match for another runtime, as described on this page, you will be better served by a team that specializes in it. For AI features built on hosted model APIs, Node.js is fully adequate, since the heavy computation happens on the provider’s side.

Your next move

Need an API or back end built?
Tell us what it has to do.

Describe the product, the clients that will call the API and the systems it must connect to. We will reply with questions, an approach and a realistic range.