I Built a TypeScript Backend Framework Because I Was Tired of Wiring Everything Together

I Built a TypeScript Backend Framework Because I Was Tired of Wiring Everything Together

1 6
calendar_today agoschedule3 min read

Every time I started a new Node.js backend project, I found myself doing the same thing.

Set up routing.

Add validation.

Configure authentication.

Connect PostgreSQL.

Add WebSockets.

Set up background jobs.

Generate API documentation.

Configure security middleware.

Install another package.

Then another one.

And another.

At some point, I realized I was spending a lot of time assembling the backend instead of building the actual product.

That frustration led me to build StreetJS.

What is StreetJS?

StreetJS is an open-source, TypeScript-first backend framework built directly on Node.js.

The idea is simple:

Give developers more of the backend infrastructure they repeatedly need, without forcing them to assemble everything from separate libraries.

StreetJS currently provides functionality for:

  • REST APIs
  • Authentication and authorization
  • Request validation
  • PostgreSQL and database access
  • WebSockets and realtime applications
  • Server-sent events
  • Background jobs
  • OpenAPI
  • Security features
  • Observability
  • AI integrations
  • Plugins

The framework is designed around TypeScript from the beginning, rather than adding TypeScript support afterward.

Why build another Node.js framework?

I'm not trying to claim that Express, Fastify, NestJS, or other Node.js frameworks are bad.

They've all solved important problems.

The question I kept asking was:

What would a backend framework look like if we designed it today around the things modern applications repeatedly need?

That question became the foundation of StreetJS.

One of the design principles is reducing unnecessary dependency exposure.

For example, StreetJS includes native implementations for parts of the backend stack instead of requiring developers to install a separate package for every capability.

The goal isn't "zero dependencies at any cost."

The goal is:

Know what your application depends on and keep the infrastructure understandable.

A simple example

A controller can look like this:

@Controller('/users')
export class UsersController {
  constructor(
    @InjectRepository(User)
    private readonly users: Repository<User>,
  ) {}

  @Get('/')
  async list(ctx: StreetContext) {
    ctx.json({
      users: await this.users.findAll(),
    });
  }
}

The idea is to keep application code focused on application behavior.

You shouldn't have to spend half your project writing infrastructure glue.

TypeScript-first

StreetJS is designed for developers who want strong typing throughout their backend.

The framework embraces:

  • strict TypeScript
  • ESM
  • decorators
  • type inference
  • runtime validation
  • typed repositories
  • typed application APIs

The objective is to catch problems as early as possible while still providing a practical runtime validation layer.

Realtime isn't an afterthought

Modern applications aren't only request/response APIs.

Chat applications, dashboards, collaboration tools, notifications and live systems need realtime communication.

StreetJS includes WebSocket and SSE capabilities as part of the framework ecosystem rather than requiring developers to build a completely separate realtime architecture.

And I'm still building it

StreetJS is open source, and I'm still learning from every release.

There are things I want to improve.

There are architectural decisions I want to revisit.

There are features that need better documentation.

And there are plenty of things I haven't figured out yet.

That's actually one of the reasons I'm sharing the project with other developers.

I'd rather build it in public and get challenged by people who have different experiences than build it in isolation.

If you're building Node.js backends...

I'd genuinely like to hear your opinion.

What is the most repetitive part of starting a new backend project for you?

Is it:

  • Authentication?
  • Database setup?
  • Validation?
  • Testing?
  • Deployment?
  • Realtime communication?
  • API documentation?
  • Project architecture?
  • Something else?

I'm particularly interested in hearing from developers who have built production Node.js applications.

You can explore StreetJS here:

GitHub: https://github.com/hassanmubiru/StreetJS

Documentation: https://hassanmubiru.github.io/StreetJS/

npm: https://www.npmjs.com/package/streetjs

If you're interested in trying it, a new project can be scaffolded with:

npx @streetjs/cli create my-app

I'd love your feedback—especially criticism.

Building a framework is easy to start.

Building one that developers actually want to use is the real challenge.

🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelski - Apr 23

Merancang Backend Bisnis ISP: API Pelanggan, Paket Internet, Invoice, dan Tiket Support

Masbadar - Mar 13

The Sovereign Vault — A Comprehensive Guide to Protocol-Driven AI

Ken W. Algerverified - Jun 4

Everyone says DeepSeek is cheaper, but I got tired of guessing the exact math. So I built a calculat

abarth23 - Apr 27

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan - Feb 9
chevron_left
202 Points8 Badges
Kenyateeb.com
3Posts
2Comments
2Connections
Am kotlin and flutter Developer

Related Jobs

View all jobs →

Commenters (This Week)

6 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!