FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Exercises and Phase Exit
Exercises and Phase Exit Prove that the database is understood before adding Prisma
The next phase should feel like an abstraction over concepts you already control, not a rescue from concepts you skipped.
Connect → Create → Query
→ Inspect → Clean up →
A phase is complete when you can perform and explain the workflow.
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Exercises and Phase Exit
Level 1 - Follow 1. Create or open the TaskFlow development Supabase project. 2. Run the server-information query in SQL Editor. 3. Copy the Session pooler settings without exposing the password. 4. Connect with psql . 5. Create the temporary practice tables. 6. Insert and query sample rows. 7. Drop the temporary tables.
Level 2 - Modify 1. Add an optional notes text column to practice_tasks . 2. Add a new project and two tasks. 3. Write a query that lists unfinished tasks ordered by priority. 4. Use a transaction to change two rows, inspect them, then roll back.
Level 3 - Implement Without copying the lesson SQL, create a temporary table called practice_tags and a join table representing a many-to-many relationship between practice tasks and tags. Add sensible keys and constraints, seed data, then write a join that returns task title + tag name.
Level 4 - Engineer Design a short connection strategy note for three future deployments:
For each, choose direct/session/transaction mode and explain the tradeoff. Do not choose by memorized port number alone.
Debugging scenarios Scenario A - Authentication failure psql reports password authentication failure. List the evidence you would check before resetting the entire project.
Scenario B - Direct host timeout The credentials are correct but the direct endpoint times out from home internet. What network capability might be missing, and which connection mode would you test next?
Volume 03 - Database Engineering Book 9 of Phase 08
FULL_STACK_DEVELOPER_2026_COMPLETE - Phase 08 Exercises and Phase Exit
Scenario C - Table visible in dashboard but API later says relation does not exist List database/schema/connection assumptions that should be verified before editing the ORM model.
Architecture oral exam 1. Is Supabase the ORM? Explain. 2. Why can direct and session-pooler URLs both use port 5432 but have different hosts/usernames? 3. Why is port 6543 not automatically "better"? 4. Why should the browser never receive our PostgreSQL password? 5. What does sslmode=require protect, and what does it not fully verify? 6. What does psql prove before Prisma is installed? 7. Why do we query the actual server version instead of assuming it?
Phase 08 checkpoint
[ ] Supabase development project exists.
[ ] You can explain Supabase vs PostgreSQL.
[ ] You can choose a connection mode deliberately.
[ ] Database credentials are outside Git.
[ ] psql connects over SSL.
[ ] You ran Phase 07 relational SQL against the real database.
[ ] You inspected tables and constraints.
[ ] You intentionally cleaned up practice objects.
[ ] You can diagnose common connection failures by layer.
[ ] You can explain what Prisma will add next.NestJS → Prisma 7.9.1 → Supabase PostgreSQL
Phase 09 introduces a typed ORM and migration workflow only after the database and connection are independently verified.
In Phase 09 we install the hard-locked Prisma 7.9.1 toolchain, initialize it in apps/api , understand schema.prisma versus prisma.config.ts , configure the PostgreSQL adapter, generate the client, and create the first migration workflow.
Official references used for this phase (verified 2026-09-17): Supabase Database Overview - https://supabase.com/docs/guides/database/overview Connect to your database - https://supabase.com/docs/guides/database/connecting-to-postgres Connecting with psql - https://supabase.com/docs/guides/database/psql Tables and data - https://supabase.com/docs/guides/database/tables Securing your data - https://supabase.com/docs/guides/database/secure-data PostgreSQL 18 psql - https://www.postgresql.org/docs/18/app-psql.html
Volume 03 - Database Engineering Book 9 of Phase 08
Exercises and Phase Exit matters because it changes a real boundary in TaskFlow. The goal is to understand the inputs, owner, observable output, and failure modes before adding more abstraction.
Restate the goal of “Exercises and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: application → connection configuration → Supabase Postgres → database evidence. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A Supabase project configured for TaskFlow development with documented connection paths and safe environment variables.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
Input -> owner -> transformation -> observable output -> failure evidenceDo not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Exercises and Phase Exit” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Compare direct and pooled connection strings and document when each is appropriate.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Committing database credentials
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.