Why SQL for FE

I've spent years treating the database as a black box behind /api/.... At some point the box starts leaking - and SQL is what's inside.

The honest pitch

As a front-end person you already speak data: arrays of objects, nested includes, filter chips, infinite scroll, dashboard cards with counts.

SQL is just… that language, but on the server's side of the wall. Tables instead of arrays. Rows instead of objects. WHERE instead of .filter(). JOIN instead of "the API returned company nested under each contact".

You don't need to become a DBA. You need enough SQL to:

• read a migration or a Prisma schema without sweating
• understand why an endpoint is slow when the list grows
• sketch a schema when you're pairing on a feature
• stop nodding politely when someone says "N+1"

Mental model vs the SPA

In the browser you often think:

const contacts = await fetch('/api/contacts?q=ada&page=1').then(r => r.json())

Behind that, something roughly like:

SELECT id, name, email, company_id
FROM contacts
WHERE name LIKE '%ada%' OR email LIKE '%ada%'
ORDER BY name
LIMIT 20 OFFSET 0;

Same job. Different syntax. The API is a polite translator.

Where this tutorial goes

1. Basics - select, filter, write, nulls, aggregates
2. Structure - tables, keys, joins, indexes
3. Practice - a small CRM schema + queries a CRM page would need

I've kept the dialect to SQLite so you can practice in a file without installing Postgres. The ideas transfer.

What we're not doing

We're not building a production CRM product. We're building the shape of one - schema + queries - so the UI mental model clicks.

Ready? Next stop: Setup.