1// REST: Resource-oriented design
2// ✅ Good REST design — nouns, proper verbs, status codes
3import express from 'express';
4 
5const router = express.Router();
6 
7// GET /users/:id — fetch single resource
8router.get('/users/:id', async (req, res) => {
9  const user = await db.users.findById(req.params.id);
Always return 404 for missing resources — not 200 with null body
10  if (!user) return res.status(404).json({ error: 'User not found' });
11  return res.status(200).json(user);
12});
13 
14// POST /users — create resource (returns 201 Created)
15router.post('/users', async (req, res) => {
201 Created signals to clients they can fetch the new resource
16  const user = await db.users.create(req.body);
17  return res.status(201).json(user);              // 201, not 200
18});
19 
20// PATCH /users/:id — partial update (not PUT which replaces)
PATCH for partial update; PUT replaces the entire resource
21router.patch('/users/:id', async (req, res) => {
22  const user = await db.users.update(req.params.id, req.body);
23  return res.status(200).json(user);
24});
25 
204 No Content is idiomatic for successful DELETE
26// DELETE /users/:id — idempotent deletion
27router.delete('/users/:id', async (req, res) => {
28  await db.users.delete(req.params.id);
29  return res.status(204).send();                  // 204 No Content
30});
31 
32// ❌ Common REST mistakes
33// POST /getUser          — verb in URL
34// GET /users/delete/123  — action in URL
35// DELETE /users with 200 — wrong status code

1// GraphQL: Schema-first design with resolvers
2import { makeExecutableSchema } from '@graphql-tools/schema';
3import DataLoader from 'dataloader';
4 
5// 1. Define the schema (this is your API contract)
6const typeDefs = `
Schema is the contract. Change it carefully — breaking changes break all clients
7  type User {
8    id: ID!
9    name: String!
10    email: String!
11    posts: [Post!]!          # relationship resolved lazily
12  }
13 
14  type Post {
15    id: ID!
16    title: String!
17    author: User!
18  }
19 
20  type Query {
21    user(id: ID!): User
22    users(limit: Int = 20): [User!]!
23  }
24 
25  type Mutation {
26    createPost(title: String!, authorId: ID!): Post!
27  }
28`;
DataLoader batches all userLoader.load() calls within one tick into a single DB query
29 
30// 2. DataLoader prevents N+1 queries
31const userLoader = new DataLoader(async (userIds: readonly string[]) => {
32  const users = await db.users.findMany({ where: { id: { in: [...userIds] } } });
33  return userIds.map(id => users.find(u => u.id === id) ?? null);
34});
35 
36// 3. Resolvers — field-level functions
37const resolvers = {
38  Query: {
39    user: (_: unknown, { id }: { id: string }) => db.users.findById(id),
40    users: (_: unknown, { limit }: { limit: number }) => db.users.findMany({ limit }),
41  },
42  User: {
Without DataLoader here, 100 posts = 100 DB calls. With it = 1 batch query
43    // Called once per User, but DataLoader batches the DB calls
44    posts: (user: User) => db.posts.findByAuthorId(user.id),
45  },
46  Post: {
47    author: (post: Post) => userLoader.load(post.authorId), // batched!
48  },
49};

1// 1. Define the contract in .proto file
2syntax = "proto3";
3 
4package user;
5 
6service UserService {
7  rpc GetUser (GetUserRequest) returns (UserResponse);
8  rpc ListUsers (ListUsersRequest) returns (stream UserResponse); // server streaming
stream keyword = server-side streaming. Client gets results as they arrive
9  rpc WatchUsers (stream UserFilter) returns (stream UserResponse); // bidirectional
Bidirectional streaming — both sides send and receive independently
10}
11 
12message GetUserRequest {
13  string id = 1;
14}
15 
16message UserResponse {
17  string id = 1;
18  string name = 2;
int64 for timestamps avoids timezone bugs. Proto3 has no Date type
19  string email = 3;
20  int64 created_at = 4;  // epoch millis — no timezone ambiguity
21}
22 
23// Generated TypeScript client (from protoc):
24// const client = new UserServiceClient('user-service:50051', credentials);
25// const user = await client.getUser({ id: '123' });
26// → Makes binary HTTP/2 call. No JSON parsing. ~10μs latency vs ~1ms REST.