The full stack learning path, simplified.

• Everything that runs in the browser: the pages, the buttons, the forms. Built with HTML for structure, CSS for looks and JavaScript for behaviour.
• No framework. Plain HTML files, a stylesheet and JavaScript that runs when the page loads.
• The front-end does not keep the data. It shows data it receives from the back-end and sends the user's input back.
• It never talks to the database directly. The browser cannot be trusted with a database password.

• A program that runs on a server and waits for requests from the front-end. We build it as an ASP.NET Core Web API in C#.
• Each URL it answers is called an endpoint. For example GET /api/expenses returns the list of expenses.
• It checks the input, applies the rules of the application (who is allowed to do what, what counts as valid) and reads or writes the database.
• It sends back a response, usually JSON, that the front-end can show.

• PostgreSQL is a relational database. Data is stored in tables, every table has columns, every record is a row.
• Tables are linked with keys: a primary key identifies a row, a foreign key points to a row in another table.
• You talk to it in SQL: SELECT, INSERT, UPDATE, DELETE.
• It is the only part that survives a restart. If the server reboots, the data is still there.

• HTTP is the protocol of the web. The browser sends a request, the server sends back a response. Nothing happens without a request first.
• A request has a method and a URL. GET reads, POST creates, PUT updates, DELETE removes.
• A response has a status code: 200 OK, 201 created, 400 bad input, 404 not found, 500 server error.
• Both sides send data as JSON. The front-end uses fetch to send the request and reads the JSON that comes back.

See it happen

Change the name or the value, press Send, and watch the data travel. The JSON keys on the left become the properties of the C# object on the right.

{
  "name": "Coffee",
  "value": 3.5
}

{
  "name": "Coffee",
  "value": 3.5
}

public class Expense
{
    public string Name { get; set; }
    public decimal Value { get; set; }
}

expense.Name = …
expense.Value = …

// Front-end (JavaScript in the browser)
const response = await fetch('/api/expenses', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Coffee', value: 3.5 })
})
const expense = await response.json()

// Back-end (ASP.NET Core minimal API)
app.MapPost("/api/expenses", async (Expense expense, AppDbContext db) =>
{
    db.Expenses.Add(expense);
    await db.SaveChangesAsync();
    return Results.Created($"/api/expenses/{expense.Id}", expense);
});

• Entity Framework Core (EF Core) lets the back-end work with the database using C# classes instead of writing SQL by hand.
• A C# class is an entity. EF Core maps it to a table: the class becomes the table, its properties become the columns, each object becomes a row.
• The DbContext is the door to the database. It holds a DbSet for every table and the connection string.
• You query with LINQ in C#. EF Core translates it to SQL, sends it to PostgreSQL through the Npgsql provider, and turns the rows back into objects.
• Migrations keep the database in step with your classes. Change a class, add a migration, and EF Core creates or alters the tables.

// Entity: becomes the "Expenses" table
public class Expense
{
    public int Id { get; set; }          // primary key
    public string Name { get; set; }
    public decimal Value { get; set; }
}

// DbContext: the door to PostgreSQL
public class AppDbContext : DbContext
{
    public DbSet<Expense> Expenses { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseNpgsql("Host=localhost;Database=expenses;Username=app;Password=secret");
}

// LINQ in C# ...
var bigOnes = await db.Expenses.Where(e => e.Value > 10).ToListAsync();
// ... becomes SQL in PostgreSQL
// SELECT "Id", "Name", "Value" FROM "Expenses" WHERE "Value" > 10