Stop 04 · JavaScript & TypeScript for BackendTopics · 6/12

Interfaces

In short

Your API passes users, orders and payments between files all day. An interface describes each shape once, so every file agrees on what a User actually looks like.

Defining the shape of request bodies, database models and API responses so TypeScript can verify your backend code handles them consistently.

The mascot fills in a long paper form with rows of boxes at a counter window.

Think of it like this

The railway reservation form

The form has fixed boxes: name, age, gender, berth preference. Leave a required box empty and the clerk sends you back. An interface is that form for objects: it lists the fields and their types, and TypeScript is the strict clerk.

Watch it happen

Interfaces that build on each other

BaseEntity

id: string

createdAt: Date

User

email: string

phone?: string

Admin

permissions[]

1/4BaseEntity holds fields every database record has: an id and a creation date.

The big ideas

What you need to know

Describe an object's shape

An interface lists property names and types. Any object missing a required field is flagged.

Optional with ?

phone?: string means the field may be missing. TypeScript then makes you check it before use.

readonly fields

readonly id: string stops code from changing the id after the object is created.

extends to reuse

interface Admin extends User copies all User fields and adds more, so you don't repeat yourself.

See it in code

Walk through the code

1interface User {2  readonly id: string;3  name: string;4  email: string;5  phone?: string;6}7 8interface Admin extends User {9  permissions: ("orders:read" | "orders:write")[];10}11function sendWelcome(user: User) {12  console.log(`Mail to ${user.email}`);13  user.phone?.startsWith("+91");14}15const a: Admin = { id: "u1", name: "Neha", email: "n@x.in", permissions: ["orders:read"] };16sendWelcome(a); // OK: an Admin is also a User

1/4User has a readonly id, two required fields and an optional phone.

An Admin can be passed where a User is expected because it has every User field. TypeScript compares shapes, not names.

Save yourself the pain

Common mistakes

Oops

Copying the same five fields into User, Admin and Seller interfaces.

Do this instead

Put shared fields in one base interface and extends it. Change it once, every type updates.

Oops

Making every field optional so objects are easy to create.

Do this instead

Only mark fields optional if they really can be missing. Otherwise you'll null-check everywhere.

Your mission

Model an order

~20 min

Quick check

interface User { name: string; phone?: string }. Which object is valid?

Go deeper

1Define an interface for your main data model (e.g. `User`) and reuse it across your API.
2Practice optional and readonly properties for fields that aren't always present.
3Learn when to extend one interface from another to avoid duplication.