Practical engineering notes explained in plain language, with enough depth for working developers and enough context for people still getting comfortable with the concepts.
In Part 1, we talked about treating entities, migrations, and repositories as production contracts. In this chapter, we move closer to the query layer: how to avoid N+1 queries, shape reads intentionally, paginate safely, keep transactions honest, add indexes that match real access patterns, and use PostgreSQL features without giving up TypeORM's ergonomics.
A practical guide to AI-native engineering as a disciplined process: choosing tools, building a strong project harness, writing better prompts, reviewing generated code, and fitting AI into the full software delivery lifecycle.
This post is a field guide to using ORMs well, with TypeORM as the main example. The examples use TypeScript, NestJS, PostgreSQL, and TypeORM, but the deeper rules apply to other ORMs as well. We’ll walk through how to leverage TypeORM to build solid databases, craft efficient queries, and structure your data, and without further ado, let’s dive in.
This post breaks down the difference between direct service calls, jobs and workers, and event-driven flows in plain terms, with a simple way to decide when each one makes sense.
This post explains how to build a lightweight publish-and-subscribe (PubSub) layer inside a NestJS monorepo, why that can be a smart early choice, and when it is time to move to a heavier tool like Kafka or RabbitMQ.
This post explains what event-driven systems are, why teams use them, how they fit inside a NestJS monorepo, and which design habits keep them understandable instead of chaotic.
This post breaks down three qualities every modern backend needs, what they mean in simple terms, and which practical architecture choices usually help teams reach them without unnecessary complexity.
This post explains Angular signals in beginner-friendly language, what problem they solve, where they fit compared to RxJS, and why they make component state easier to reason about.
This post explains why important system knowledge should live in the repository as code or versioned configuration, and how that makes teams faster, safer, and easier to onboard.