Learning path map
Detailed Content
⚡ Vercel
The fastest way to put a site online: connect GitHub and, with each push, Vercel publishes your project automatically. Deploy with one click.
Deploy is the act of taking your project and putting it on a public server, at an address anyone can access. Vercel is a platform that does this almost automatically.
Only you can see code on your computer. Deploying is what turns the project into something real and shareable. Vercel makes this step simple and free.
Vercel is ideal for modern sites and apps (React, Next.js, HTML). It watches your repository and redeploys whenever you make a change, with no manual commands.
Signing up for Vercel using your GitHub account and authorizing Vercel to see your repositories.
It’s the bridge between where your code lives (GitHub) and where it will be published (Vercel). Without this connection, there’s no automatic deploy.
Use “Sign up with GitHub” to create an account that’s already connected. Authorize only the repositories you want to publish. The free plan (Hobby) is enough to get started.
The step of importing a repository into Vercel and clicking “Deploy.” In seconds, your project gets a working public address.
It’s the "live" moment in Trail 2: seeing your site running at a real URL proves that the deploy cycle works from end to end.
Vercel automatically detects the project type. You get an address projeto.vercel.app. From then on, each git push redeploys.
For each branch or pull request, Vercel creates a "preview" deploy: a copy of the site with its own address, separate from the production version.
Lets you test a change at a real link before modifying the main site. You can show someone the new version without risking the live one.
The branch main becomes production; the others become previews. Each preview has a unique URL and disappears when the branch is removed.
The Vercel settings dashboard: build command, project root directory, domains, and the button to redeploy a deployment.
Projects grow and need adjustments. Knowing where to make changes helps you avoid the classic “it works on my PC, but breaks on deploy.”
In most cases, the defaults are already fine. Change "Root Directory" if the project is in a subfolder. "Redeploy" repeats the last deploy.
Change the default address projeto.vercel.app through a custom domain you bought, such as seusite.com.
A custom domain looks professional and is easier to share. Vercel takes care of HTTPS automatically, for free.
Add the domain under “Domains” and point the DNS as Vercel indicates. The HTTPS certificate (padlock) is generated automatically.
🗃️ Supabase
A database without the hassle: Supabase gives you a ready-to-use database, with an automatic API and user login, all through your browser.
A database is an organized place to store information permanently: users, orders, messages. Think of it as a giant, reliable spreadsheet that many programs can read and write at the same time.
Almost every real app needs to remember something from one visit to the next. Without a database, everything is lost when the page closes.
The data is stored in tables (rows and columns). Supabase uses PostgreSQL, a powerful, free database, behind the scenes.
The step of creating an account, opening a new project, and letting Supabase provision a PostgreSQL database ready to use.
Setting up a database from scratch used to be complicated. Supabase delivers one in just a few clicks, without you installing anything.
Choose a region near you and keep the database password safe. The free plan is enough for learning and prototyping.
The database structure: each table stores one type of thing (e.g., "users"), the columns are the fields (name, email), and the type defines what each column can contain (text, number, date).
A good structure prevents clutter and errors. Defining the right tables and types at the start saves you a lot of headaches later.
Create tables using the visual "Table Editor." Common types: text, int, bool, timestamp. Every line has a id unique.
The two most common actions in a database: insert (write a new row) and query (retrieve rows that match a criterion). It’s the database’s version of “write and read.”
Every app depends on this: save what the user types and show back what has already been saved. Without inserts and queries, the database just sits there.
You can insert data through the screen or with code. The language behind it is SQL (insert, select), but Supabase also lets you do everything visually.
As soon as you create a table, Supabase automatically generates an API: ready-to-use endpoints for your site to read and write data in the database over the internet.
Normally, you would need to program an entire server for this. Having a free API connects your frontend to the database in minutes.
Each project has a URL and a key (anon key). The library supabase-js makes calls easier. This is the hook for the APIs module.
Supabase’s ready-made system for user registration and login: email and password, or signing in with Google and GitHub, without having to build it from scratch.
Secure login is difficult to get right. Using a ready-made solution prevents serious failures and lets you focus on the rest of the app.
Supabase manages passwords and sessions. With access rules (RLS), each user can only see their own data. Enable the providers in the Authentication tab.
🔌 APIs
APIs are how services communicate with each other over the internet. Learn how to request and send data, test, and handle errors safely.
An API is a set of addresses that a program uses to request information from another program. Think of a waiter: you place an order, they take it to the kitchen and bring you the dish; you don’t need to know how the kitchen works.
Everything on the modern web communicates through APIs: weather, maps, payments, your database in Supabase. Understanding APIs means understanding how apps connect.
You send a request to a URL and receive a response, almost always in JSON format. Most web APIs use HTTP.
The four basic API verbs: GET reads, POST create, PUT updates and DELETE deletes. Each one describes the intent of the request.
Using the right verb makes the API predictable and organized. It’s the standard vocabulary every web service understands.
Remember CRUD: Create=POST, Read=GET, Update=PUT, Delete=DELETE. GET must never change data; POST e PUT send a body with the information.
Two ways to test an API without writing an app: the curl makes the call from the terminal; Thunder Client is a VS Code extension with a visual interface for this.
Before connecting the API to your site, it’s essential to check that it responds as expected. Testing first saves hours of debugging.
curl -X GET url makes the simplest call. Thunder Client saves your requests and displays the formatted response. Always check the status code.
Use your site’s JavaScript to call an API and show the result on the screen. The browser’s standard tool for this is the fetch.
It’s what makes a website "live": it fetches data on the spot and updates the page without reloading. That’s the heart of any dynamic app.
fetch(url) returns a promise; use await e .json() to read the response. Calls are asynchronous: the code waits for the response to arrive.
Open APIs anyone can use to get ready-made data: weather forecasts, addresses based on ZIP codes (ViaCEP), currency exchange rates, and much more.
They're the easiest way to practice: you get real data right away without setting up a server. You can enrich your app with little effort.
Some require a free key (API key); others, like ViaCEP, are open. Read the documentation to find out the URL and response format.
The practice of anticipating that an API might fail (the internet goes down, data doesn’t exist, the service is offline) and showing a clear message instead of breaking the app.
In the real world, requests fail. An app that handles errors well seems professional; one that freezes at the first failure frustrates the user.
Status 200 and success; 404 not found; 500 server error. Use try/catch and check response.ok before using the data.
🔑 Environment Variables
Secure secrets: passwords and keys should never be in your code. Environment variables keep these secrets outside your project, securely.
Environment variables are values stored outside the code, such as an API key or database password. The program reads them when it runs, without them being written into the project.
Let you separate “how the app works” (code) from “which secrets it uses” (configuration). Changing a secret doesn’t require modifying the code.
They're pairs NOME=valor. The same code runs differently in each environment (your PC, production) just by changing the variables.
A file called .env in the project root where you write your variables, one per line, to use while developing on your computer.
It’s the standard way to store secrets during development without writing the key directly into code that goes to GitHub.
Format CHAVE=valor, without spaces. The .env needs to go in the .gitignore (seen in Track 1) so it never gets uploaded.
The Vercel dashboard where you add the same variables as in the .env, but for the site that's live. Since the .env isn't uploaded; Vercel needs to receive the secrets here.
Without this, your published site can’t access the database or APIs. This is the step that securely connects the deploy to your secrets.
Add it under “Settings → Environment Variables.” You can separate them by environment (Production, Preview). After making changes, redeploy.
GitHub Actions runs automatic tasks (tests, deploys) with each push. "Secrets" are where you store keys for those tasks to use securely.
Automations also need secrets, but they should never be written in the configuration file. Secrets solve this.
Add it under "Settings → Secrets and variables → Actions". In the workflow, you access them with ${{ secrets.NOME }}. They appear masked in the logs.
The golden rule: passwords, API keys, tokens, and the .env must never go on GitHub. Once they’re in the history, they stay there forever.
Leaking a secret in a public repository is one of the most common and dangerous mistakes: bots scan GitHub for keys to misuse.
Always set .env no .gitignore. Check with git status before the commit. If it leaked, consider the key compromised and replace it.
Rotation is the process of generating a new key and discarding the old one, periodically or when a leak is suspected. It’s like changing the lock for security.
Old keys that have already been exposed are a risk. Rotating them limits the damage: even if a key leaks, it will soon stop working.
Generate the new key in the service, update it everywhere (.env, Vercel, Actions), and only then revoke the old one so you don't break the app in the middle.