71  71. Project Architecture

71.1 Technical “Stack” (or just “tech stack”)

The following diagram highlights the various parts of the app and where they will be running. See below for an explanation of the diagram.

71.1.1 The following image is in the video:

71.1.2 I updated the image to make it a little more clear and accurate

71.2 Project Architecture

71.2.1 Frontend: Code that runs in the Browser

  • Next.js
  • Client library for Supabase integration

71.2.2 Backend: Web Server

  • Vercel
  • Next.js server side components

71.2.3 Backend: Supabase

  • PostgreSQL database

  • Storage system for storing the image files (similar to Amazon S3 storage)

  • Edge functions: small programs that run on Supabase’s servers; see Edge Functions below.

  • Built-in authentication system

71.2.4 Edge Functions

An Edge Function is a small program that runs on Supabase’s servers, not in the user’s browser. It waits until something calls it, by visiting its web address, does one job, sends back an answer, and stops. You don’t rent or manage a server for it: you upload the code, and Supabase runs it whenever it’s called. (This kind of hosting is called serverless; see “Virtual servers, containers, and serverless” in Hosting and Deployment.) “Edge” means that Supabase can run the function on servers in many places, close to the user.

Why the app needs them: some jobs need a secret key, and anything that runs in the browser can be read by anyone who opens the page. So the browser asks an Edge Function, and the function uses the key on the server, where nobody can see it. The task app has three, in the folder supabase/functions:

Edge Function What it does Secret keys it uses
create-task-with-ai Saves a new task and sends its title and description to OpenAI, which picks a label OPENAI_API_KEY
create-stripe-session Opens Stripe’s payment page or customer portal STRIPE_SECRET_KEY, STRIPE_PRICE_ID
stripe-webhook Receives Stripe’s message that a payment went through, and upgrades the user STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET

The keys reach the functions as secrets: named values that you store on Supabase with npx supabase secrets set NAME=value. The function’s code reads them by name; they never appear in the code or on GitHub. The functions are written in TypeScript and run on Deno, a JavaScript runtime similar to Node.js. In theory Supabase could have used Node.js; Deno is a common choice for TypeScript, and the reasons are beyond this tutorial.

71.2.5 Backend: Third-Party Services

  • Google Cloud (for OAuth)
  • OpenAI API (for asking AI to pick an appropriate “tag” for each task)
  • Stripe (for payment processing)

71.3 Where Docker fits

Every part of the backend in the diagram runs on someone else’s computers: Vercel hosts the website, Supabase hosts the database, storage, authentication and edge functions, and Google, OpenAI and Stripe run their own services. So you don’t need Docker for this project, but you’ll hear about it.

Docker packages a program together with everything it needs (the right versions of its language, libraries and settings) into a container that runs the same way on any computer. A container image is the packaged program; a container is a running copy of it (Hosting and Deployment introduces the idea).

Professional teams often also run a complete copy of Supabase on their own laptops, to experiment without touching the real project. The Supabase CLI does this with npx supabase start, which downloads Supabase’s container images and runs them in Docker: a local database, local logins, local storage, and a local dashboard. That copy would replace the “Backend: Supabase” box in the diagram with containers on your own computer.

This course doesn’t do that: Docker needs a fairly recent computer and several GB of disk space. If you want to try it anyway, see “Deeper dive: Docker, and running Supabase on your own computer” in Step 5a: Supabase CLI command.

71.4 Keeping notes - Setup checklist

Over the course of this tutorial we will have to address all of the following in order to set up this project to work. The pages that follow go into more detail about each of these topics:

Many of these steps require keeping track of numerous URLs, “keys” and other “configuration information” for your project. Often the “configuration information” is generated on one website (e.g. Vercel, Supabase, Google Cloud console, Stripe) and must be copied to a different website or recorded in a specific file on your computer.

Keeping track of all this information can get VERY confusing, so keep it in one place: the course’s Task App Setup Worksheet (Excel). You type each value once on its My Info sheet (the Where to find it column says where on each website to look), and its Commands sheet builds the exact lines you copy into .env.local, the terminal and the websites. That makes it much easier to review your setup and debug it when there are problems. You can add your own notes, or screenshots in a separate document, to remember where you got each value and where you copied it to.

Much of this configuration information is “secret info”, like your passwords. Treat the worksheet as you would treat your passwords: keep it in ~/projects/full-stack-demo-app, next to the task-app folder and not inside it, so Git can never upload it to GitHub, and don’t share it.

71.5 Further Learning - tutorial folder

To learn more about the technologies listed above you can look at your project’s tutorial/ folder. This info was prepared by the original developer of this tutorial project and includes:

  • Detailed auth guides.
  • Database and RLS walkthroughs.
  • Edge Function examples.
  • Storage and Stripe integration deep dives.

71.6 Further Learning - official documentation

You can also refer to official docs:

Practice Questions

Easy

Question 1 · Multiple choice

In this project, which code runs in the user’s browser?

  1. The PostgreSQL database
  2. The client-side part of the Next.js web app (HTML, CSS and JavaScript), including the Supabase client library
  3. The Supabase edge functions
  4. Stripe’s payment processing

b. The frontend is the code that runs in the browser: the client-side portion of the Next.js app, plus the client library it uses to talk to Supabase. The database (a) and the edge functions (c) run on Supabase’s servers, and Stripe (d) runs on Stripe’s own servers.

Question 2 · Matching

Match each part of the architecture with its job.

Part Job
1. Vercel A. stores the app’s data
2. Supabase PostgreSQL database B. stores the uploaded image files (similar to Amazon S3)
3. Supabase storage C. the web server that runs the server side of the Next.js app
4. Supabase edge functions D. lets users log in with their Google account
5. Google Cloud (OAuth) E. processes payments
6. OpenAI API F. TypeScript functions that run on Supabase’s servers
7. Stripe G. uses AI to pick a “tag” for each task

1 → C, 2 → A, 3 → B, 4 → F, 5 → D, 6 → G, 7 → E.

Question 3 · True or false

In this project, Vercel stores the image files that users attach to their tasks.

False. Image files go into Supabase’s storage system (similar to Amazon S3). Vercel is the web server that hosts the Next.js app.

Question 4 · Fill in the blank

Supabase edge functions are written in ______ and run on ______’s servers, using the ______ runtime environment instead of Node.js.

TypeScript; Supabase; Deno.

Question 5 · Short answer

What is a “tech stack”? Name the main technologies in this project’s tech stack.

A tech stack is the set of technologies an app is built from (languages, frameworks and services), together with where each part runs. This project’s tech stack:

  • Next.js, running partly in the browser and partly on Vercel’s web server
  • Supabase: PostgreSQL database, storage, authentication and edge functions
  • third-party services: Google OAuth, the OpenAI API and Stripe

Medium

Question 6 · Ordering

Put the setup checklist in the order the page gives:

  • Deploy edge functions
  • Set up Stripe
  • Run the database migrations
  • Clone the project from GitHub
  • Deploy the app to production (Vercel)
  • Run and test the application on your computer
  • Create Supabase project
  • Check the storage bucket
  • Configure OpenAI API
  • Set up the Supabase CLI
  • Set up Google OAuth
  1. Clone the project from GitHub
  2. Create Supabase project
  3. Set up the Supabase CLI
  4. Set up Google OAuth
  5. Configure OpenAI API
  6. Set up Stripe
  7. Run the database migrations
  8. Check the storage bucket
  9. Deploy edge functions
  10. Run and test the application on your computer
  11. Deploy the app to production (Vercel)

The logic: you need the code first; the Supabase project has to exist before the CLI can be linked to it and before other services can be connected to it; the migrations are run with the CLI, and they create the storage bucket, so you check the bucket after running them; the edge functions use the OpenAI and Stripe keys, so they are deployed after those services are set up; you run and test the app on your computer once everything is connected; and you deploy it to production last, once it works.

Question 7 · Short answer

Look at the architecture diagram. Which part of Supabase connects to Google OAuth, and which part connects to the OpenAI API and Stripe?

Authentication connects to Google OAuth: Supabase’s login system lets users sign in with their Google account. Edge functions connect to the OpenAI API and Stripe: they are server-side code, so they can safely use those services’ secret keys.

Question 8 · Short answer

Why does the page recommend keeping all your setup information in one place (the setup worksheet), and what goes in it?

Setup produces many URLs, keys and other configuration values. A value is often created on one website (Vercel, Supabase, Google Cloud console, Stripe) and must be copied to another website or into a specific file on your computer. Keeping everything in one place makes it much easier to review your setup and to debug problems.

It holds the keys, URLs and other configuration values (the My Info sheet), and it builds the exact lines you copy from them (the Commands sheet). Your own notes or screenshots of where each value came from help too.

Question 9 · Multiple choice

Your setup worksheet contains API keys and other configuration values. How should you treat it?

  1. Keep it inside the task-app folder and commit it, so you never lose it
  2. Like your passwords: keep it private and don’t share it
  3. Paste it into the project’s README so teammates can find it
  4. Share it freely - configuration values are never secret

b. Much of this information is secret, just like a password: anyone who has your secret keys could use your accounts. Options (a) and (c) would publish the secrets to everyone who can see the repository, and (d) is simply not true.

Question 10 · True or false

Supabase had no choice but to use Deno for its edge functions, because Node.js could not have been used for this.

False. The page says that, in theory, Supabase could have used Node.js. Deno is often chosen as a runtime environment for TypeScript. Both Deno and Node.js are runtime environments: programs that run JavaScript code outside a browser.

Hard

Question 11 · Scenario

For each problem below, which part(s) of the architecture would you investigate first?

  1. “Log in with Google” fails.
  2. Tasks save correctly, but attaching an image to a task fails.
  3. New tasks are saved but never get an AI tag.
  4. The page for upgrading to a paid subscription doesn’t work.
  1. Supabase authentication and the Google OAuth setup in Google Cloud.
  2. Supabase storage.
  3. The edge functions and the OpenAI API (for example, a missing or wrong API key).
  4. Stripe and the edge functions that work with it.

The diagram tells you which pieces work together for each feature, so you know where to start looking; your setup notes tell you which keys and URLs you entered where.

Question 12 · Long answer

Explain the difference between the frontend and the backend in this project. Why is the backend spread across several companies’ servers (Vercel, Supabase, Google, OpenAI, Stripe) instead of running on one computer?

The frontend is the client-side part of the Next.js app (HTML, CSS, JavaScript) running in the user’s browser: what the user sees and clicks. The backend is everything that runs on servers: Vercel runs the server-side part of the Next.js app; Supabase runs the PostgreSQL database, file storage, authentication and edge functions; and Google, OpenAI and Stripe provide login, AI and payments.

The backend is spread out because each company specializes in one hard job. Instead of building your own login system, payment processing or AI model, you use theirs and connect them with keys and URLs. The trade-off is more accounts, keys and settings to manage - which is why setup is the hard part, and why the page recommends keeping careful notes.

Question 13 · Short answer

The diagram shows Next.js in two places: in the browser and on Vercel’s web server. Why?

A Next.js web app has two portions. The client-side portion (HTML, CSS and JavaScript) is sent to the user’s browser and runs there. The server-side portion is JavaScript that runs in Node.js on the web server (Vercel). One Next.js project produces the code for both places.

Question 14 · Scenario

A friend tells Maria: “To build a full-stack app with a database, you have to install Docker first.” Is that true for this project? Explain, using the architecture diagram, and say when Docker would be needed.

Not for this project. Everything that runs on a server runs on someone else’s computers: Vercel hosts the website, and Supabase hosts the database, storage, authentication and edge functions (Google, OpenAI and Stripe run their own services). Nothing has to run in containers on Maria’s computer.

Docker packages a program with everything it needs into a container that runs the same way on any computer. It would be needed if Maria wanted to run a complete local copy of Supabase on her laptop (npx supabase start), as professional teams often do to experiment without touching the real project.

© 2025-2026 Y. Rosenthal. All rights reserved.