# Full-Stack Development
and Debugging

Day 2 builds directly on the workflow from Day 1. Flag an instructor if one of these is not working before the practical portion begins.

• Run a web application locally
• Navigate a project in Visual Studio Code
• Use the integrated terminal
• Install dependencies using npm
• Use Codex or Claude Code for basic development tasks
• Use basic Git and GitHub workflows
• Commit and push project changes
• Open Browser Developer Tools

Authentication and application data are related, but they solve two different problems.

Firebase Authentication gives your application a reliable way to know who is using it.

• User registration with email and password
• User sign-in
• User sign-out
• Authentication state: is somebody currently signed in?
• User ID: a stable identifier for each account
• Authentication errors and user feedback
• Protected functionality that only appears when a user is authenticated

What the application should know

• Whether a user is signed in
• Which user is signed in
• What UI should appear in each authentication state
• How to respond when sign-up or sign-in fails

Cloud Firestore stores application data so it survives refreshes and future sessions.

A simple task document

{
  "title": "Finish project outline",
  "course": "CS 101",
  "dueDate": "2026-09-10",
  "completed": false,
  "ownerId": "firebase-user-id"
}

Authentication becomes useful when application data can be associated with the correct user. The Firebase user ID provides that connection.

• Store the authenticated user's ID with records that belong to that user
• Query for records owned by the current user
• Test with two different accounts
• Verify one account cannot see another account's private records

Security mindset

• Authentication proves identity
• Queries select data
• Security Rules enforce access
• Test with more than one account
• Never assume hiding something in the interface makes it secure

Full-stack debugging becomes much easier when you identify which layer is failing before changing code.

First locate the failing layer

UI
 ↓
Application Logic
 ↓
Authentication
 ↓
Firestore Request
 ↓
Security Rules
 ↓
Database

What to check before changing code

• What exactly did you expect to happen?
• What actually happened?
• Read the browser console error word for word
• Inspect the Network panel when a request is involved
• Check terminal output
• Check whether the current user exists
• Check the exact Firestore path or query
• Check Firebase Security Rules when requests are denied
• Give AI the collected evidence, not just the symptom

Once you have repeated a workflow enough times, you may notice checks or actions that are worth automating. Hooks can remove useful repetition from an AI-assisted development workflow.

• Understand the task before automating it
• Prioritize hooks that prevent mistakes
• Prefer simple automations over complicated ones
• Understand exactly what a hook will execute
• Do not automate a process you do not understand

Example useful automation

AI modifies code
      ↓
Run lint / tests
      ↓
Report failures
      ↓
Developer reviews result

Use these as starting structures. Replace the bracketed fields with real evidence and project context.

The instructor will continue the Study Task Tracker from Day 1 and turn it from a local-only frontend into an authenticated application with persistent, user-owned tasks.

The complete walkthrough

1. Open the Study Task Tracker from Day 1 and verify it still runs locally.
2. Confirm that task data is currently local-only and disappears when appropriate.
3. Create or open a Firebase project.
4. Register the web application with Firebase.
5. Install and initialize Firebase in the project.
6. Enable Email/Password Authentication.
7. Implement user registration.
8. Implement sign-in and sign-out.
9. Display the appropriate interface based on authentication state.
10. Create a Cloud Firestore database.
11. Design a simple task document structure.
12. Store a task in Firestore.
13. Attach the authenticated user's UID as ownerId.
14. Retrieve only the current user's tasks.
15. Add or review Security Rules for user-owned task data.
16. Refresh the page and verify tasks persist.
17. Test with a second account.
18. Verify one account cannot access another account's private tasks.
19. Introduce or encounter a real failure.
20. Locate the failing layer using DevTools and Firebase evidence.
21. Give that evidence to Codex or Claude Code.
22. Evaluate the diagnosis and proposed fix.
23. Apply the fix.
24. Test again and verify the behavior.
25. Commit the working result to GitHub.

Continue the Campus Event Board from Day 1 and convert it into a full-stack application.

Your target

Steps

1. Open your Campus Event Board from Day 1.
2. Verify the project runs locally.
3. Create or configure a Firebase project.
4. Connect Firebase to the application.
5. Enable Email/Password Authentication.
6. Implement user registration.
7. Implement sign-in.
8. Implement sign-out.
9. Make the interface respond appropriately to authentication state.
10. Create a Firestore database.
11. Store event data in Firestore.
12. Add the authenticated user's UID as ownerId when appropriate.
13. Retrieve the correct event data for the authenticated user.
14. Add or review Security Rules that protect user-owned records.
15. Refresh the app and verify persistence.
16. Sign out and sign back in.
17. Verify the correct data still appears.
18. Create or use a second account.
19. Verify private user-owned data is not exposed across accounts.
20. Use DevTools and Firebase evidence to investigate any errors.
21. Use Codex or Claude Code to assist with diagnosis if needed.
22. Test every proposed fix before trusting it.
23. Commit the working checkpoint to GitHub.

You are done when...

• A user can create an account
• A user can sign in
• A user can sign out
• Authentication state affects application behavior
• Event data is stored in Firestore
• Stored data survives a page refresh
• User-owned records contain the correct ownerId
• Security Rules protect user-owned data
• You tested the application using two accounts
• You can locate browser errors using DevTools
• You can explain which application layer failed during a bug
• Your working Day 2 implementation is committed to GitHub

When something fails, locate the layer before changing code.

If one of these is still unclear, flag an instructor before the workshop ends.

• I can explain the difference between authentication and application data
• I can create an account using Email/Password Authentication
• I can sign in and sign out
• I can detect authentication state in the application
• I can store and retrieve Firestore data
• I understand why user-owned records need an ownerId
• I understand the difference between filtering data and securing data
• I tested user-owned data with two different accounts
• I can identify which full-stack layer is failing during debugging
• I can give AI real evidence instead of only saying "fix it"
• I understand when hooks may be useful, even if I did not implement one
• My working Day 2 implementation is committed to GitHub

Use the official documentation when you need more detail than the workshop can cover.