Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
All-in-one PaaS platforms that let you deploy frontends and backends with just a few clicks seem perfect at first. The real problem starts once actual users roll in. Code that runs completely fine locally starts throwing timeouts in production, and attempting a simple DB schema change can bring down the entire service. On top of that, getting stuck in vendor lock-in with nowhere to turn can quickly become a massive headache.
Here are a few infrastructure patterns to help you enjoy the convenience of these platforms while cleanly clearing out the obstacles that follow.
While a local Node.js process stays running continuously, a serverless environment spins up briefly when a request arrives and vanishes shortly after. If you clumsily manage global variables or DB singleton connections during a cold start, your connection pool will dry up in no time.
Deploying to a staging server every time just to test isn't a viable option. Mocking the network layer itself locally and spinning up handlers is much faster.
`typescript
// src/mocks/handlers.ts
import { http, HttpResponse } from 'msw';
export const handlers = [
http.get('/api/v1/user/profile', ({ request }) => {
const authHeader = request.headers.get('Authorization');
if (!authHeader) {
return new HttpResponse(null, { status: 401, statusText: 'Unauthorized' });
}
return HttpResponse.json({
id: 'usr_102938',
email: 'dev@example.com',
role: 'ADMIN',
createdAt: new Date().toISOString()
});
})
];
// src/mocks/node.ts
import { setupServer } from 'msw/node';
import { handlers } from './handlers';
export const server = setupServer(...handlers);
`
Applying this pattern is straightforward.
setupServer when running the emulator..env.local file from the production transaction pooler endpoint.You can verify that your backend interface behaves 100% identically on your local machine without ever hitting the deploy button. Instead of wasting time on flaky remote tests, this architecture provides instant feedback as soon as you write code.
When using serverless PostgreSQL solutions like Supabase or Neon, blindly firing a simple ALTER TABLE statement is dangerous. Acquiring an ACCESS EXCLUSIVE lock on the target table causes subsequent queries to stack up in a waiting state, ultimately leading to timeout outages.
First, you should set timeout limits on your migration sessions.
`sql
SET lock_timeout = '2000ms';
SET statement_timeout = '5000ms';
ALTER TABLE users ADD COLUMN bio VARCHAR(255);
`
To safely modify a live database structure, you should use an expand-and-contract approach: expand both the code and the DB simultaneously, then trim away the old parts later.
`typescript
import { db } from './db';
interface UpdateUserProfileInput {
userId: string;
fullName: string;
}
export async function updateUserProfile({ userId, fullName }: UpdateUserProfileInput) {
await db.transaction(async (tx) => {
await tx.user.update({
where: { id: userId },
data: {
full_name: fullName,
name: fullName
}
});
});
}
`
Here are the three steps for a safe operation:
lock_timeout to create a safety net that immediately aborts the operation if lock contention occurs.Following this procedure allows you to swap out schemas without dropping a single user request.
If you rely solely on console.log in a serverless environment, logs from multiple instances get scattered and turn into a complete mess. To trace a request's path from entry to exit, a unique Request ID and structured JSON format are essential.
`typescript
import { Hono } from 'hono';
import { requestId } from 'hono/request-id';
import pino from 'pino';
const logger = pino({
level: process.env.LOG_LEVEL || 'info',
formatters: {
level: (label) => ({ level: label.toUpperCase() })
},
base: { env: process.env.NODE_ENV }
});
const app = new Hono();
app.use('', requestId());
app.use('', async (c, next) => {
const reqId = c.var.requestId;
const startTime = performance.now();
c.set('logger', logger.child({ reqId }));
await next();
const durationMs = Math.round(performance.now() - startTime);
logger.info({
reqId,
method: c.req.method,
path: c.req.path,
status: c.res.status,
durationMs
}, 'Request processing finished');
});
`
Here is a setup to avoid overage fee bombs when using external monitoring tools:
Server-Timing into response headers to send bottleneck data to your monitoring system.`typescript
import * as Sentry from '@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
tracesSampleRate: 0.1,
beforeSend(event, hint) {
const error = hint.originalException;
if (error && error instanceof Error && error.message.includes('ECONNRESET')) {
return null;
}
return event;
}
});
`
By simply filtering out meaningless 200 OK logs and noisy exceptions, you can easily keep your system controlled well within the free tier limits of your monitoring platform.
Tightly coupling platform-specific SDKs directly to your business logic means you'll have to rewrite your entire codebase if you move to another platform later. This is why you should use the Adapter Pattern—as outlined by Martin Fowler—to decouple the interface between your application's core logic and external cloud SDKs.
`typescript
export interface IStorageService {
uploadFile(path: string, fileBuffer: Buffer, mimeType: string): Promise<{ url: string }>;
deleteFile(path: string): Promise;
}
import { S3Client, PutObjectCommand, DeleteObjectCommand } from '@aws-sdk/client-s3';
export class S3StorageAdapter implements IStorageService {
private s3: S3Client;
private bucket: string;
constructor(region: string, bucket: string) {
this.s3 = new S3Client({ region });
this.bucket = bucket;
}
async uploadFile(path: string, fileBuffer: Buffer, mimeType: string): Promise<{ url: string }> {
await this.s3.send(new PutObjectCommand({
Bucket: this.bucket,
Key: path,
Body: fileBuffer,
ContentType: mimeType
}));
return { url: https://${this.bucket}.s3.amazonaws.com/${path} };
}
async deleteFile(path: string): Promise {
await this.s3.send(new DeleteObjectCommand({ Bucket: this.bucket, Key: path }));
}
}
`
Automate data backups as well so that you can exit at any time.
`bash
#!/usrbin/env bash
set -euo pipefail
TIMESTAMP=(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/tmp/db_backup_{TIMESTAMP}"
S3_BUCKET="s3://my-app-exit-backups/pg_dumps"
export PGPASSWORD="${DB_PASSWORD}"
mkdir -p "${BACKUP_DIR}"
pg_dump -h "{DB_PORT}" -U "{DB_NAME}"
-Fc --exclude-table-data='logs_*' > "${BACKUP_DIR}/full_schema_data.dump"
tar -czvf "{BACKUP_DIR}" .
aws s3 cp "{S3_BUCKET}/{R2_ENDPOINT_URL}"
rm -rf "{BACKUP_DIR}.tar.gz"
`
pg_dump to extract your schema and data.crontab so backup files are shipped to Cloudflare R2 or an external S3 bucket.Mitigating the risk of vendor lock-in makes it significantly easier to handle infrastructure price hikes or platform outages when they occur.