Movies

{{ movie.title }}

\n```\n\nRight-click, view page source, and you'll see none of the curly braces made it to the browser. The template gets rendered on the server and all of that is replaced before it's sent.\n\nYou'll also notice it isn't a full HTML document. Let's fix that:\n\n```xml\n\n\n \n \n Movies\n \n \n

Movies

{{ movie.title }}

\n \n\n```\n\nThe title is what shows up in the browser tab, which is nicer than staring at the URL. I auto-formatted this with the Prettier extension, that's just editor stuff, format it by hand if you'd rather.\n\nThis is also where CSS classes would go on these elements, and where you'd attach your stylesheets. We're not going deep on the front end here, but now you know how the HTML is supposed to be structured.\n\n## Migrations and the admin site\n\nWe have a view and a template and completely fake data. Real data means models, and that circles back to those migration warnings.\n\n**Migrations** represent changes to a database. Think about wanting to move a database from one computer to another. Migrations let us do that without hand-keeping a pile of SQL `CREATE` statements, Django tracks it all for us.\n\nThere are 18 of them already there in a brand new project. Apply them:\n\n```bash\npython manage.py migrate\n```\n\nA wall of OKs. I ran that in a second terminal tab so the server could keep running in the first, and remember to activate the virtual environment in the new tab.\n\nNow `/admin` gives us a login page instead of an error. We need a user to log in with:\n\n```bash\npython manage.py createsuperuser\n```\n\nIt asks for a username, an email, and a password. I used `admin` and `password`, and it warns you the password is too common. You can bypass that, and I'm only doing it for learning's sake.\n\nLog in and you get the site administration page with an authentication and authorization section. Those are the default tables that came from the migrations. Open Users and there's the account we just made, with a hashed password, since the actual password value is never stored in the database, only the hash, which gets checked against on login.\n\nAnything we build ourselves, we'll want to add to this panel so we can do CRUD on it without writing a form for everything.\n\nAll of this is sitting in `db.sqlite3` in your files. SQLite is a fine database for learning, and moving to Postgres later is not bad because of migrations and the abstraction Django gives you.\n\n## The ORM\n\nWhich is the other half of it. You are not writing SQLite directly. You're using an **ORM**, an object relational mapper, which takes Python objects and relates them to rows in the database.\n\nThat means the database underneath can be swapped for another relational database without rewriting all of your code. You get to stay in plain Python and still work with a database. It costs a little extra learning up front with migrations and models, and after that it's pretty good.\n\n## Our first model\n\nA model is the columns of a table. We are not creating an individual movie here, we're describing what a movie looks like.\n\nNew file, `movies/models.py`:\n\n```python\nfrom django.db import models\n\n\nclass Movie(models.Model):\n title = models.CharField(max_length=200)\n year = models.IntegerField()\n```\n\nThe naming of the file matters. The class inherits from `models.Model` with a capital M, and by convention the class name is capitalized too.\n\nEach attribute gets a field type assigned to it. `CharField` is for characters and needs a `max_length`. `IntegerField` is for the year. You could give either one a `default` if you wanted, we're leaving them without.\n\nSo the difference between this and a regular Python class is that it inherits from `models.Model` and it lives in a `models.py`.\n\nOur movie has no relationships, so it doesn't come up here, but the moment you add a `ForeignKey` to another model you have to pass `on_delete`, like `models.ForeignKey(Studio, on_delete=models.CASCADE)`. That argument used to be optional in much older Django and it is required now, so a relationship copied out of an old tutorial without it will refuse to even load.\n\n## Creating a migration\n\nMake sure your app is in `INSTALLED_APPS` (we did that already) because that's how migrations find it. Then:\n\n```bash\npython manage.py makemigrations movies\n```\n\nYou'll get `Migrations for 'movies'` and `+ Create model Movie`, plus the filename it wrote in the new `migrations` directory. Open it if you're curious. It describes the change to the data structure, and you don't really need to be able to read it.\n\nIt gets turned in to SQL, and you can see exactly what SQL:\n\n```bash\npython manage.py sqlmigrate movies 0001\n```\n\nThere's the `CREATE TABLE` with an `id` field we never defined, auto incrementing, plus title and year. You never have to run `sqlmigrate`, it doesn't do anything, it just shows you what applying the migration will do.\n\nOne difference from what's on screen in the video: that `id` column comes out as a `bigint` now, not a plain integer. Newer Django puts `DEFAULT_AUTO_FIELD = \"django.db.models.BigAutoField\"` in the generated `settings.py`, so the primary key it makes for you is the bigger type by default. Nothing for you to change, your SQL just reads a little different than mine.\n\nThen apply it:\n\n```bash\npython manage.py migrate\n```\n\nYou can name the app on the end if you want, `python manage.py migrate movies`. Either works. Naming it matters when you have several apps and need to be specific, otherwise it applies everything not already applied.\n\n## Adding the table to the admin site\n\nWe have a movies table and you're just going to have to trust me bro, because you can't see it anywhere yet. New file, `movies/admin.py`:\n\n```python\nfrom django.contrib import admin\n\nfrom .models import Movie\n\nadmin.site.register(Movie)\n```\n\nI don't have this one memorized either, I looked it up. It's [in the docs](https://docs.djangoproject.com/en/stable/intro/tutorial02/) and it's the same three lines every time.\n\nRefresh the admin site and nothing happens, because this runs on server startup. Restart the server and there's our Movies table.\n\nAdd a movie through it. Jaws, and I looked up the year, 1974. Save.\n\n## Overriding `__str__()`\n\nThe list shows `Movie object (1)`, which tells you nothing. We can change the string representation of the object by overriding a method on the model:\n\n```python\nclass Movie(models.Model):\n title = models.CharField(max_length=200)\n year = models.IntegerField()\n\n def __str__(self):\n return f\"{self.title} from {self.year}\"\n```\n\n`self` gets us at the attributes on that instance, and the f-string fills them in. Refresh and it says \"Jaws from 1974\". Any time we print the object, that's what shows up.\n\n## Working with real data\n\nNow let's throw out the mock data and pull movies from the database. Back in `movies/views.py`:\n\n```python\nfrom django.http import HttpResponse\nfrom django.shortcuts import render\n\nfrom .models import Movie\n\n\ndef movies(request):\n data = Movie.objects.all()\n return render(request, \"movies/movies.html\", {\"movies\": data})\n```\n\n`Movie.objects.all()` gets every row. If you forget the dictionary and pass the query set straight through, you get \"context must be a dict rather than QuerySet\", so wrap it.\n\nI also had a naming mismatch the first time, the template is looping over `movies` and I'd called the key `data`. Keep the key and the template variable the same and it works.\n\nRefresh and there's Jaws. Add the other two through the admin page and the list fills out.\n\n## Parameterized URLs\n\nThe next logical step is clicking a movie to get a detail page. That needs a parameter in the URL.\n\nThis time let's write the view first, in `views.py`:\n\n```python\ndef detail(request, id):\n data = Movie.objects.get(pk=id)\n return render(request, \"movies/detail.html\", {\"movie\": data})\n```\n\n`pk` is the primary key, and `id` is coming in as an extra argument to the view. Where from? The URL. In `urls.py`:\n\n```python\npath(\"movies/\", views.detail),\n```\n\nThe angle brackets capture that piece of the URL, `int` says what type it is, and `id` is the name it arrives under in the view. So the name inside the brackets has to match the parameter name on your function.\n\nVisit `/movies/1` and you get \"template does not exist\", along with every directory Django searched, which is genuinely useful output. Make `movies/templates/movies/detail.html`:\n\n```xml\n{{ movie }}\n```\n\nThere's Jaws from 1974, which is our `__str__` doing its thing.\n\n## Dynamic links\n\nIf Jaws is id 1, Sharknado is 2, and The Meg is 3, then clicking each one should go to `/movies/1`, `/movies/2`, `/movies/3`. So the href is just the id of whatever element we're on.\n\nIn `movies.html`, wrap the title in an anchor:\n\n```xml\n

\n```\n\nI'm writing the leading slash on that href, which is a small fix on what's typed on camera. Without it the browser resolves the link relative to the current URL, and since our path is `movies` with no trailing slash you'd land on `/1` instead of `/movies/1`. The absolute path works either way.\n\nThe whole movie object is passed to the page, so we can reach `movie.id` as we iterate. Hover the links and you'll see `/movies/1` and friends down in the corner. Click through and you get the detail page.\n\nIf you want to go further, look up removing hard-coded URLs and namespacing URLs with the `{% url %}` tag, covered in [tutorial 3](https://docs.djangoproject.com/en/stable/intro/tutorial03/). We're not doing it here, it mostly pays off when you move your app around and don't want to fix a pile of links. Ours is one link repeated three times, so not a big deal.\n\n## Creating a form\n\nNow imagine a link that brings up a form for adding a movie. New path:\n\n```python\npath(\"movies/add\", views.add),\n```\n\nAnd a link at the bottom of `movies.html`, after the unordered list:\n\n```xml\nadd a movie\n```\n\nRefresh and it's broken, `module 'movies.views' has no attribute 'add'`. Makes sense, it doesn't exist. Add it:\n\n```python\ndef add(request):\n return render(request, \"movies/add.html\")\n```\n\nNow it says template does not exist, so we're on the right track.\n\nIt doesn't matter how many times I write a form in HTML, I always forget the exact setup. Here's `movies/templates/movies/add.html`:\n\n```xml\n\n```\n\nThe `action` is where the data gets sent, and we're sending it right back to the same path. The submit input's `value` is the text on the button.\n\nOn the text inputs, you have two options for the sample text. The one you'll usually see is `value`, but that's not very friendly, the user has to delete it before typing. `placeholder` disappears as soon as you type, which is a much better experience.\n\nYou can also add a label instead, or both:\n\n```xml\nmovie title\n```\n\nI removed mine and kept the placeholders.\n\nSubmit that form without the `{% csrf_token %}` line and you get CSRF verification failed. That's cross-site request forgery. Since we're posting back to our own URL, Django gives us a token to make it work, and that one template tag is all it takes.\n\n## Handling the POST\n\nThe `add` view now does double duty: it shows the form page, and it accepts the data typed in to it. So inside the view, we check whether data came in.\n\nA POST is different from a GET. A GET is what happens when you visit a page, like `/movies/1` where the value rides along in the URL. In a POST that information is not in the URL, it's in the request body. Open Chrome's network tab, submit the form, and look at the payload, you'll see title and year sitting in there.\n\nYou pull those out with `request.POST`, which is a dictionary:\n\n```python\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .models import Movie\n\n\ndef add(request):\n title = request.POST.get(\"title\")\n year = request.POST.get(\"year\")\n if title and year:\n movie = Movie(title=title, year=year)\n movie.save()\n return HttpResponseRedirect(\"/movies\")\n return render(request, \"movies/add.html\")\n```\n\nI use `get` rather than square brackets on purpose. `get` does not throw if the key isn't there, and it isn't there the first time you load the form page with no post data. Square brackets would work the same when the data exists, but blow up when it doesn't, and then I'd need a `try` around it, which I don't want to deal with.\n\nThere are other request types, `PUT` and `DELETE` among them, but GET and POST are the two you'll see constantly. Do your own research on the rest.\n\nCreating the object doesn't save it, `save()` does. Then we send the user back to the list with a redirect.\n\nAdd a movie and it drops you back on `/movies` with the new one in the list, and its detail link works right away.\n\n## Deleting data\n\nSame idea, going the other direction. First let's make `detail.html` a little less bare, and add the delete link:\n\n```xml\n

\ndelete\n```\n\nHover it and you get `/movies/delete/11` or whatever the id is. Now the URL and the view. In `urls.py`:\n\n```python\npath(\"movies/delete/\", views.delete),\n```\n\nAnd the view, which takes the id the same way `detail` does:\n\n```python\ndef delete(request, id):\n Movie.objects.get(pk=id).delete()\n return HttpResponseRedirect(\"/movies\")\n```\n\nGet the object, call `delete()` on it, redirect back to the list. Click delete on a movie and it's gone.\n\n## 404s\n\nWe haven't done any error checking. Go to `/movies/delete/39` for an id that doesn't exist and you get an exception, `Movie matching query does not exist`. It breaks, and then it's broken.\n\nSo instead of deleting immediately, hold the object in a variable and put the lookup in a `try`:\n\n```python\nfrom django.http import Http404, HttpResponseRedirect\n\n\ndef delete(request, id):\n try:\n movie = Movie.objects.get(pk=id)\n except Movie.DoesNotExist:\n raise Http404(\"movie does not exist\")\n movie.delete()\n return HttpResponseRedirect(\"/movies\")\n```\n\nIf we make it past the `except`, no exception was thrown and we still have the object, so we can delete it then. 404 means not found, by the way.\n\nNow `/movies/delete/39` gives page not found and deleting a real one still works.\n\n> [!tip]\n> Django has a shortcut for exactly this, `get_object_or_404(Movie, pk=id)`, which does the try and the raise in one line. The [detail views section](https://docs.djangoproject.com/en/stable/intro/tutorial03/) of the docs covers it. I wrote the long version so you can see what it's doing.\n\nThat 404 page says you're seeing it because `DEBUG = True` in your settings. In deployment debug should be false, so let's see what that looks like. In `movies/settings.py`:\n\n```python\nDEBUG = False\n```\n\nSave and you get an error, you must set `ALLOWED_HOSTS` if debug is false. I tried `localhost` first and got a bad request 400, because I'm browsing the loopback address, not `localhost`. The host has to match what's in the URL bar:\n\n```python\nALLOWED_HOSTS = [\"127.0.0.1\"]\n```\n\nRestart the server, refresh, and now you get a plain \"Not Found, the requested resource was not found on this server\". That's what a visitor sees in deployment. You can customize the 404 page, we're not getting in to that here.\n\nAt this point you have essentially all of CRUD: create, read, and delete. We never did update. Our data is simple enough that an update is really just a delete followed by a create, but if you want a next challenge, build a form that edits an existing movie instead of making a new one. That matters a lot once records have ten fields and you only want to change one of them, like someone editing a profile.",[],[],"5eaf6664-088b-4a89-8bca-946c22e7accd",4026,"django-crash-course-introduction-python-web-development-tutorial","Phoenix Framework REST API Crash Course - Introduction + Full Elixir API Tutorial",31,"## Timestamps\n\n- `00:00` - Intro\n- `01:20` - What is Elixir Phoenix\n- `03:38` - MVC Pattern\n- `05:49` - Installation\n- `08:25` - Project Structure\n- `10:03` - Main files\n- `11:08` - Other Folders\n- `12:12` - Create a Repo\n- `13:59` - Basic Application Architecture\n- `16:12` - Adding a New Page with Mock Data\n- `22:24` - Creating an API\n- `22:49` - Working with the Database\n- `31:53` - Routes\n- `32:48` - Updating a Resource\n- `34:45` - Delete\n- `35:23` - Users and Relationships\n- `36:01` - Update the Model\n- `37:23` - Making the association in models\n- `40:25` - Nested Data in API Calls\n- `43:17` - Get a User's Posts\n- `48:21` - Conclusion\n\nElixir is the programming language, Phoenix is the web framework built on top of it.\n\nPhoenix is pretty much always used for the back end, so before anything else it's worth being clear on what a back end even is. When you visit a website you're looking at the front end, the nice visual of the data. That data got fed to it from somewhere else, and that somewhere else is the back end. What looks like one application is usually at least two.\n\nThe back end takes data from a database (sqlite, Postgres, MySQL, plenty of others) and hands it to the front end in a predictable format. That format is **JSON**, which is just a way to represent data as text. A back end that lets you request certain information and get it back as JSON is an **API**.\n\nBy the end of this you'll have a working API that pulls from a database and returns JSON.\n\nThe prerequisite is my [Elixir Programming Introduction](https://youtu.be/-lgtb-YSUWE). That one covers the language itself, this one is applying it to the web. All the code for this one is up at [github.com/CalebCurry/elixir-phoenix](https://github.com/CalebCurry/elixir-phoenix) if something isn't working on your machine and you want to check against mine.\n\n## MVC Pattern\n\nOnce an application gets bigger you need a way to organize the code, and there are a bunch of design patterns for that. The most common is **MVC**.\n\n- Model - the data layer, talks to the database\n- View - the presentation, what gets displayed\n- Controller - sits between the two and does the actual logic\n\nThe flow is: a user hits the app, the request lands in a controller, the controller asks the model for data, the model goes to the database and hands it back, and then the controller renders a view which gets sent back to the user. Phoenix also puts a **router** in front of all that, which is the layer that associates a request path with a function in a controller.\n\nIn an API the view isn't an HTML page, it's the JSON structure. Same idea, different output. There's probably variations of this diagram all over the internet so I'm not saying this is the only way to think about it, but it's the pattern Phoenix recommends and the one we'll follow.\n\n## Installation\n\nPhoenix ships as a Mix archive, so first you need Hex:\n\n```bash\nmix local.hex\nmix archive.install hex phx_new\n```\n\n`phx_new` is what gives us the `mix phx.new` generator. The basic way to make a project is `mix phx.new `, which assumes you want a database and that the database is Postgres. I want sqlite3 instead, it's just easier to get going with:\n\n```bash\nmix phx.new forum --database sqlite3\n```\n\nAccepted values for `--database` are `postgres`, `mysql`, `mssql`, and `sqlite3` ([the full option list is here](https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html)). If you don't want a database at all, `--no-ecto`. I do want one.\n\nPhoenix uses **Ecto** to talk to the database, which is an ORM. The nice part is the database you pick isn't a huge deal, if you're on Postgres and I'm on sqlite the application code looks pretty much the same, Ecto abstracts away the database specific stuff.\n\nIt'll ask to fetch and install dependencies, say yes. Then:\n\n```bash\ncd forum\nmix ecto.create\nmix phx.server\n```\n\nThe default config is fine so `mix ecto.create` just works, and you'll see `forum_dev.db` show up. `mix phx.server` runs the app on port 4000, so command-click (or control-click on Windows) the address and you'll get the Phoenix landing page. That's your first Phoenix website. It's local and it's basically nothing, but it's a start.\n\nIf you want to change the port or anything else, that lives in `config/dev.exs`.\n\n## Project Structure\n\nIt generates a LOT of files, so here's where to find what.\n\nFirst the hidden stuff, the directories starting with a dot or an underscore. You don't usually go in and tinker with these:\n\n- `_build` - build artifacts, generated on the fly, safe to delete\n- `.elixir_ls` - language server files, from the Elixir LS extension\n- `.gitignore` - this one you DO edit, it's what keeps build artifacts out of your repo\n- `.formatter.exs` - config for `mix format`\n\n`mix format` formats your source code. Open a second terminal tab so you keep the server running, and run it there. I have the Elixir formatter extension doing this on save, so if you see my code jump around while I'm typing, that's what that is.\n\n### Main files\n\n`mix.exs` is the project file. If you've worked with node this is basically your `package.json`, it describes the project and lists your dependencies. Scroll down and you'll see them. Add a new one to that list or change a version, then:\n\n```bash\nmix deps.get\n```\n\nYou'll need that whenever you first clone a project from GitHub too, to make sure you actually have everything.\n\nWhat gets retrieved is written down in `mix.lock`, which pins the exact versions. That matters more than it sounds, dependencies change over time and if you and another developer are on different versions the code might behave differently or not compile at all on one of your machines.\n\n### Other folders\n\n- `assets` - front-end junk, pretty much ignore it for now\n- `config` - I'll let you guess\n- `deps` - the actual downloaded dependency code, gitignored, since anyone cloning can just run `mix deps.get`\n- `priv` - accessory files that aren't directly running the app, scripts and our migrations live here\n- `test` - tests, probably not going to need it here\n- `lib` - our app code, this is the one you actually work in\n\n## Create a Repo\n\nSomething I like to do the moment a project is generated is commit the whole thing, so I have an initial commit that's a clean untouched application to revert back to. As you're learning I'd encourage the same:\n\n```bash\ngit init\ngit add .\ngit status\ngit commit -m \"init\"\n```\n\nThen `git log` shows the history. I pushed mine up to GitHub as a public repo called `elixir-phoenix` so you can follow along commit by commit and see exactly what changed at each step.\n\n## Basic Application Architecture\n\nWe can already reach the default page, so let's trace how it gets there. Available paths live in the router, at `lib/forum_web/router.ex`:\n\n```elixir\nscope \"/\", ForumWeb do\n pipe_through :browser\n\n get \"/\", PageController, :home\nend\n```\n\nA `get` with just a slash means the homepage, and it uses `PageController` and the `:home` function. So follow it through to `lib/forum_web/controllers/page_controller.ex`:\n\n```elixir\ndef home(conn, _params) do\n render(conn, :home)\nend\n```\n\nIn the video this reads `render(conn, :home, layout: false)`. Layouts got reworked in Phoenix 1.8, there's now just the one `root.html.heex` wrapping everything and the app layout is a plain function component you call from a template, so the generated controller doesn't pass `layout: false` anymore. The block above is the current version.\n\nAll it does is render. The page itself is under `lib/forum_web/controllers/page_html/home.html.heex`. There's an heex extension you can grab if you're not getting highlighting.\n\nOpen it and replace the whole thing (it's a pretty complex homepage) with:\n\n```xml\n

Hello and welcome

\n```\n\nSave, and the server rebuilds on its own, you don't have to stop and start it. Refresh and there it is.\n\nIf that felt like a lot of jumping around, it is. One more time: router takes the request and associates it with a controller, the controller does whatever application logic (here, nothing), it renders a view, the view goes back to the user. That's the MVC diagram exactly, minus the model, since we aren't touching data yet.\n\n## Adding a New Page with Mock Data\n\nNow let's build that same structure ourselves, starting with hardcoded data. Same workflow, so start at the router:\n\n```elixir\nscope \"/\", ForumWeb do\n pipe_through :browser\n\n get \"/\", PageController, :home\n get \"/users\", PageController, :users\nend\n```\n\nWe're reusing `PageController` here. On a bigger app you'd probably have a dedicated `UserController` instead.\n\nThen the function in `page_controller.ex`:\n\n```elixir\ndef users(conn, _params) do\n IO.puts(\"users function hit\")\n\n users = [\n %{id: 1, name: \"Alice\", email: \"alice@email.com\"},\n %{id: 2, name: \"Bob\", email: \"bob@email.com\"}\n ]\n\n render(conn, :users, users: users)\nend\n```\n\nSame deal as the homepage, the video passes `layout: false` here and on 1.8 you don't. If you DO want the shared chrome (a header or footer across multiple pages) you wrap the template's contents in the app layout component instead, ` ... `.\n\nThe `IO.puts` is just so you can see something show up in the terminal, and `users: users` is how the data gets handed to the view. Then create `lib/forum_web/controllers/page_html/users.html.heex`:\n\n```xml\n

Users page!

<%= user.name %> - <%= user.email %>

\n```\n\nThe template engine here is **embedded Elixir**, and all those `<%= %>` symbols are just how you mark where Elixir code starts and stops. Don't worry too much about the details, this is pretty much the last time I use it in this video, I don't usually spend a ton of time studying template engines. There are [syntax guides](https://hexdocs.pm/phoenix/components.html) if you want to go deeper.\n\nVisit `localhost:4000/users` and you get Alice and Bob, and `users function hit` in the terminal. Right click, view page source, and it's pure HTML, no Elixir anywhere. The page got generated on the back end and the finished HTML got sent to the client.\n\nThat's one way to build full stack apps and it has real limits. You're stuck on a fairly niche templating engine, which is fine for something simple but not great next to a front-end framework like React, and by default every navigation is a full page refresh, so it's not friendly for single page applications. It IS worth knowing the back end can do either, you don't technically need two separate applications.\n\n## Creating an API\n\nI want JSON instead, and that part is easy. Swap the `render` call out:\n\n```elixir\ndef users(conn, _params) do\n users = [\n %{id: 1, name: \"Alice\", email: \"alice@email.com\"},\n %{id: 2, name: \"Bob\", email: \"bob@email.com\"}\n ]\n\n json(conn, %{users: users})\nend\n```\n\n`users` is the key, the list is the value. Visit the page now and you get JSON.\n\nSo we have a JSON endpoint, it's just mocked. Time for the database.\n\n## Working with the Database\n\nThe easiest way to start is to have Phoenix generate the code and then adapt it. Ignore the users stuff for a second, we're building a forum, so let's do posts:\n\n```bash\nmix phx.gen.json Posts Post posts title:string body:string\n```\n\nThree \"posts\" in a row is confusing so here's what each one is:\n\n- `Posts` - the **context**, the module responsible for encapsulating data access. Think of this as the model part of MVC.\n- `Post` - the **schema**, which describes what a single post looks like.\n- `posts` - the plural, used for the table name.\n\nThat creates a pile of files and then prints a line to add to your router. I want the API under `/api`, so instead of pasting it where they suggest, make a new scope:\n\n```elixir\nscope \"/api\", ForumWeb do\n pipe_through :api\n resources \"/posts\", PostController, except: [:new, :edit]\nend\n```\n\n`pipe_through :api` is what lets us hang middleware off this later.\n\nThe next thing it tells you to do is apply your migrations. A **migration** describes a change to the database structure, and stacked up they show how you got from nothing to what you have now. The one that just got generated is under `priv/repo/migrations/` and it's called something like `create_posts`. It describes the change but doesn't apply it:\n\n```bash\nmix ecto.migrate\n```\n\nNow with the server running, hit `localhost:4000/api/posts` and you get an empty list. That's exactly what you want to see. It's empty because we have no posts yet.\n\n### Creating a post\n\nFor this I'm using Postman. Maybe a bad choice of example, because the \"post\" in Postman has nothing to do with posts on a forum, it's referring to a POST request. Any API testing tool works if you already have one you like.\n\nNew request, method POST, URL `http://localhost:4000/api/posts` (note there's no `s` on the `http`, we're on localhost). Then body, raw, JSON:\n\n```json\n{\n \"post\": {\n \"title\": \"My first post\",\n \"body\": \"Let me tell you about myself\"\n }\n}\n```\n\nHit send and you get the same thing back with an `id` of 1. The id comes from the database and acts as your confirmation that the insert happened. Refresh the GET in the browser and the data's there.\n\n### What the generated code is actually doing\n\nFollow the router to `lib/forum_web/controllers/post_controller.ex` and look at `create`:\n\n```elixir\ndef create(conn, %{\"post\" => post_params}) do\n with {:ok, %Post{} = post} <- Posts.create_post(post_params) do\n conn\n |> put_status(:created)\n |> put_resp_header(\"location\", ~p\"/api/posts/#{post}\")\n |> render(:show, post: post)\n end\nend\n```\n\nThat second parameter is the interesting one. It's pattern matching: take a map with a `\"post\"` key and assign the value to `post_params`. Which is exactly the shape of the JSON we sent.\n\nIf you want to see it, drop an `IO.inspect(post_params)` in there and watch the terminal.\n\nThe `with` line is doing the same trick on the result of `Posts.create_post`. Pull it apart so you can actually see what's being matched:\n\n```elixir\ndef create(conn, %{\"post\" => post_params}) do\n result = Posts.create_post(post_params)\n IO.inspect(result, label: \"db result\")\n\n with {:ok, %Post{} = post} <- result do\n conn\n |> put_status(:created)\n |> put_resp_header(\"location\", ~p\"/api/posts/#{post}\")\n |> render(:show, post: post)\n end\nend\n```\n\nInsert something and search the terminal for `db result`. It's a tuple, `:ok` first, then a `Post` struct. Now break it on purpose, change `\"title\"` to `\"tile\"` in the request body and send. You get `can't be blank`, and `db result` now has `:error` as the first value. That doesn't match the pattern, so the body of the `with` never runs.\n\nBelow that we're just building the response, `put_status(:created)` is where the `201 Created` comes from, then the headers, then a render. That render still goes through a template, it just produces JSON. You'll find it in `lib/forum_web/controllers/post_json.ex`:\n\n```elixir\ndef show(%{post: post}) do\n %{data: data(post)}\nend\n```\n\nChange `data:` to `post:` and the top level key in your response changes. Same for `index`. You can still think of `post_json.ex` as the view layer, it's just handing back JSON instead of HTML.\n\n## Routes\n\nA lot of this got wired up by convention. To see everything you have:\n\n```bash\nmix phx.routes\n```\n\nGetting the list is `index`, getting one is `show`, then `create`, then `update` (twice, once for PATCH and once for PUT), then `delete`. The `:id` in a path is the part you pass in, so `/api/posts/1` hits `show` and gets you that one post.\n\n## Updating a Resource\n\nThere are two methods for updating and they run the same function here. In general PUT replaces a resource and PATCH updates it, meaning with a PATCH anything you leave out keeps whatever it had.\n\nIn Phoenix, by default, both of them behave like a PATCH. Send a PUT to `/api/posts/1` with just a title and the title changes, but the body stays exactly where it was. So it's not really a replace.\n\nBecause of that I'd use PATCH when I'm updating, just for clarity. If you want a real replace you could write a separate function for PUT where leaving out `body` actually removes it, feel free to do that as an exercise. I think the default behavior is fine.\n\n## Delete\n\nThis one's easy, which is about the only thing I'm good at. Send a DELETE to `/api/posts/1` and you get back a `204 No Content`, which is a pretty normal response for a delete since there's no body to give you. Send it again and you get a `404`, because the thing you're trying to delete isn't there anymore.\n\nThat's your full CRUD: create, read, update, delete.\n\n## Users and Relationships\n\nNext up, a user who owns posts. This is relationships, which gets a little more involved, so if what we've covered is already enough for what you need, no biggie. It's really not too bad though.\n\nSame generator as before, different arguments:\n\n```bash\nmix phx.gen.json Accounts User users name:string email:string:unique\n```\n\n`:unique` on the email is an extra attribute type you can tack on. Right before running this I made a commit, which makes it very easy to see exactly what files the command added.\n\nAdd the line it prints to the API scope:\n\n```elixir\nscope \"/api\", ForumWeb do\n pipe_through :api\n resources \"/posts\", PostController, except: [:new, :edit]\n resources \"/users\", UserController, except: [:new, :edit]\nend\n```\n\nThat mock users route from earlier was just for demonstration, I'm removing it. Then apply the new migration:\n\n```bash\nmix ecto.migrate\n```\n\n### Update the model\n\nWe have a users table now, but nothing connects a post to a user. That needs a `user_id` column on posts, which means a new migration:\n\n```bash\nmix ecto.gen.migration add_user_id_to_posts\n```\n\nOpen that file and it's empty, it has no idea what you want. Describe the change yourself:\n\n```elixir\ndef change do\n alter table(:posts) do\n add :user_id, references(:users, on_delete: :nothing)\n end\nend\n```\n\nThe `alter table` wrapper is the part that's easy to forget. Leave it off and `mix ecto.migrate` gives you `cannot execute command outside of block`, which is not the most obvious error message in the world. With it in place:\n\n```bash\nmix ecto.migrate\n```\n\n### Making the association in models\n\nThat changed the database but not our code. Open `lib/forum/posts/post.ex` and there's no mention of a user anywhere, so the association needs made in two places, once on each schema.\n\nPost belongs to a user:\n\n```elixir\nschema \"posts\" do\n field :title, :string\n field :body, :string\n belongs_to :user, Forum.Accounts.User\n timestamps(type: :utc_datetime)\nend\n```\n\nThat's application, then context, then schema. And a user has many posts, over in `lib/forum/accounts/user.ex`:\n\n```elixir\nschema \"users\" do\n field :name, :string\n field :email, :string\n has_many :posts, Forum.Posts.Post\n timestamps(type: :utc_datetime)\nend\n```\n\n## Nested Data in API Calls\n\nTo test this we need a user first. New request in Postman, POST to `/api/users`:\n\n```json\n{\n \"user\": {\n \"name\": \"Caleb\",\n \"email\": \"caleb@example.com\"\n }\n}\n```\n\nSend, and you get back an id of 1.\n\nNow try to create a post owned by that user:\n\n```json\n{\n \"post\": {\n \"title\": \"My second post\",\n \"body\": \"Some content\",\n \"user_id\": 1\n }\n}\n```\n\nThe post gets created but the `user_id` does NOT get attached. There's a structure in the database, sure, but there's also application level validation, and that's the changeset. Look at the bottom of `post.ex`, it only casts body and title. Add the new field:\n\n```elixir\ndef changeset(post, attrs) do\n post\n |> cast(attrs, [:body, :title, :user_id])\n |> validate_required([:body, :title, :user_id])\nend\n```\n\nSend it again and it still doesn't show up in the response. But drop `user_id` out of the request now and you get `can't be blank`, which tells you it IS reaching the database, it's just not being displayed.\n\nDisplaying it is a view concern, so `post_json.ex`:\n\n```elixir\ndef data(%Post{} = post) do\n %{\n id: post.id,\n body: post.body,\n title: post.title,\n user_id: post.user_id\n }\nend\n```\n\nNow it comes back. Fetch the earlier posts and you'll see the split: the one you made right after fixing the changeset has a `user_id` (it made it to the database, it just wasn't being returned), and the ones before that have nothing, because the value never got that far.\n\nSo there's two pieces here, the view decides what shows up in the API and the schema decides what's allowed through to the database. Neither one needs a migration, because we're changing how the application works, not the database structure.\n\n## Get a User's Posts\n\nRequest a user right now and the posts aren't included. Partly that's display, but there's one more thing first: the data has to be **preloaded**.\n\nRelated data doesn't get retrieved by default, on purpose. If all you want is the user's name it'd be a waste to go collect every post they've written, and on a complicated database with a lot of relationships you really don't want it wandering off into every other table on its own. So you say when you want it, in the context, at `lib/forum/accounts.ex`:\n\n```elixir\ndef get_user!(id), do: Repo.get!(User, id) |> Repo.preload(:posts)\n```\n\nThen the display side, in `lib/forum_web/controllers/user_json.ex`. You can't just stick `user.posts` in the map, a list of structs isn't something it can render, you'll get an undefined error. What you can do is copy the pattern that's already there and loop:\n\n```elixir\nalias Forum.Posts.Post\n\ndefp data(%User{} = user) do\n %{\n id: user.id,\n name: user.name,\n email: user.email,\n posts: for(post <- user.posts, do: post_data(post))\n }\nend\n\ndefp post_data(%Post{} = post) do\n %{\n id: post.id,\n title: post.title,\n body: post.body\n }\nend\n```\n\nThe alias is just so you don't have to write out the fully qualified name every time you use it. Get user 1 now and you get the user plus a nested list of their posts.\n\nThere's a cleaner way though. `PostJSON` already has a function that does exactly this shape, so instead of writing a second one, drop the `defp` down to `def` in `post_json.ex` so it's public, then reuse it:\n\n```elixir\nalias ForumWeb.PostJSON\n\ndefp data(%User{} = user) do\n %{\n id: user.id,\n name: user.name,\n email: user.email,\n posts: Enum.map(user.posts, &PostJSON.data/1)\n }\nend\n```\n\nSame result, and this version includes the `user_id` too, since that was the one difference between the function I wrote and the one that was already sitting there. `Enum.map` takes the list and a function, and `&PostJSON.data/1` is the capture syntax for passing that function along.\n\nThat's a foundation. There's obviously a lot more you could do from here, the obvious next one being letting a user register and log in so they can only create posts as themselves, which is a decent thing to try implementing on your own.\n\nThis and the [Elixir Programming Introduction](https://youtu.be/-lgtb-YSUWE) are the first Elixir content I've done on YouTube, so I'm genuinely unsure what you all want next. Drop a comment and let me know.",[],[],"34cba287-c9db-41ba-9014-5a893502e7e1",2954,"phoenix-framework-rest-api-crash-course-introduction-full-elixir-api-tutorial","Django REST Framework - Build an API from Scratch",30,"## Timestamps\n\n- `00:00` - Introduction\n- `02:05` - Create a virtual environment\n- `03:38` - Install packages\n- `04:01` - Create our Django project\n- `05:36` - Apply migrations\n- `06:31` - Intro to admin site\n- `07:31` - Create our model\n- `08:50` - Create our own migration\n- `12:37` - Start REST framework\n- `13:43` - Create our serializer\n- `14:53` - Create our view endpoints\n- `18:57` - CRUD\n- `22:28` - POST request\n- `27:17` - Drink details - GET\n- `32:50` - Drink details - PUT\n- `34:22` - Drink details - DELETE\n- `36:25` - Getting JSON through browser\n- `37:59` - Consuming the API\n\nAn API allows multiple applications to communicate with one another. If you can describe all of your data in a consistent format, typically JSON, you can send and receive that data between totally different apps.\n\nStack Overflow has one. Instagram has one. Google has like a bajillion of them. And typically an API lets you view data, create new data, update data, and delete data, which is what we're going to build here.\n\nThis one starts from nothing. No prior project, no prior code, empty directory. It takes a little extra time at the beginning to get everything set up, but then we're all on the same page. I did this same thing with Flask in an earlier video, so this is the Django version of that. Django is a bit more involved, so if you want more background on the framework itself my Django crash course covers it, though it's not a prerequisite here.\n\nThe app is called `drinks`, a little API for getting information about your favorite beverages.\n\n## Virtual Environment\n\nYou need Python 3 for all of this. If you don't have it, grab it from [python.org](https://www.python.org/downloads/).\n\nFirst off, a directory to work in:\n\n```bash\nmkdir drinks\ncd drinks\n```\n\nBefore installing anything, we want a **virtual environment**. That's where all the dependencies for this project live, so you don't get clashing versions across projects.\n\n```bash\npython3 -m venv .venv\n```\n\nThat creates a `.venv` directory, and since it starts with a dot you'll need `ls -a` to see it.\n\nAt this point I open the whole `drinks` directory in VS Code (File > Open Folder), because then any terminal you open is already in the right path.\n\nNow activate it:\n\n```bash\n. .venv/bin/activate\n```\n\nYou'll see `(.venv)` show up on the left of your prompt. You go through that activation anytime you want to work on the project, including in every new terminal tab you open.\n\n## Install packages\n\n```bash\npip install django\npip install djangorestframework\n```\n\nDjango is the framework, Django REST framework is the tool we're going to use to actually build the REST API on top of it.\n\nOnce Django is installed you can just run `django-admin` by itself and it prints out every command available to you. `runserver`, `startproject`, all of it.\n\n## Create our Django project\n\n```bash\ndjango-admin startproject drinks .\n```\n\nThe `.` at the end means put it in the current directory. Without it you'd get another folder wrapped around everything.\n\nSo now inside our outer `drinks` directory we have an inner `drinks` directory. Seeing the same name twice is a little strange, but the outer one can be named whatever you want, I only made it so the virtual environment and `manage.py` sit together.\n\nSpeaking of, `startproject` gives you a `manage.py`. Think of it as a wrapper around `django-admin` that does a little extra setup for you.\n\n```bash\npython manage.py runserver\n```\n\nThat starts the server at [http://127.0.0.1:8000](http://127.0.0.1:8000). Open it and you get the Django welcome page. Don't get too excited, we have a lot more to do.\n\n## Apply migrations\n\nThe first thing you'll see is a complaint about 18 unapplied migrations. **Migrations** represent the data structure for your database, and they need applied before the tables actually exist.\n\nI leave the server running and open a second terminal tab, activate the virtual environment there, then:\n\n```bash\npython manage.py migrate\n```\n\nA bunch of OKs scroll by and the essential tables are created.\n\n## Intro to admin site\n\nDjango has an admin page that lets you see your tables and the data inside them. It's handy when you're building an API because you can check your work against the database instead of guessing.\n\nGo to [http://127.0.0.1:8000/admin](http://127.0.0.1:8000/admin) and you'll get a login, except there's no user yet. Make one:\n\n```bash\npython manage.py createsuperuser\n```\n\nIt asks for a username, an email, and a password. I went with `admin` and a really lame password, and it complains about security, which you can override by typing `y`.\n\nLog in and you'll see the tables Django made for you. Now we want our own table in there.\n\n## Create our model\n\nWhatever your API is about, you need a model that represents it. In our case, what does a drink look like? The model is just a Python class with some attributes, and as your app grows you get more and more models and the database gets more complex.\n\nInside the inner `drinks` directory, make a new file `models.py`:\n\n```python\nfrom django.db import models\n\n\nclass Drink(models.Model):\n name = models.CharField(max_length=200)\n description = models.CharField(max_length=500)\n```\n\nTwo things tell Django this is a model: it's in `models.py`, and it inherits from `models.Model`.\n\nThe attributes get a data type off of `models`, and there are a bunch of them. `CharField` is the one we want, and it takes a `max_length`. I don't know what the world's longest drink name is, but I highly doubt there's much out there over 200 characters.\n\nWe're not creating a specific drink here, we're describing what every drink should look like.\n\n> [!tip]\n> Normally you'd run `python manage.py startapp drinks` to get an app with all of these files scaffolded for you. Here I'm just adding the files to the project package by hand, which works fine, it's just why we have to register `drinks` in `INSTALLED_APPS` in a second.\n\n## Create our own migration\n\nTo turn that class in to a database table, we make a migration:\n\n```bash\npython manage.py makemigrations drinks\n```\n\nRun it right now and you get an error:\n\n```\nNo installed app with label 'drinks'.\n```\n\nThere's a `settings.py` file in the project, and in it a list of all the apps you're using. Ours isn't on it. Add it:\n\n```python\nINSTALLED_APPS = [\n 'django.contrib.admin',\n 'django.contrib.auth',\n 'django.contrib.contenttypes',\n 'django.contrib.sessions',\n 'django.contrib.messages',\n 'django.contrib.staticfiles',\n 'drinks',\n]\n```\n\nTry again and it creates `drinks/migrations/0001_initial.py`.\n\nThe migration describes the change to our data structure, but it doesn't apply it. For that we run the same command as before:\n\n```bash\npython manage.py migrate\n```\n\nYou'll see it applying our migration this time.\n\n### Registering the model in admin\n\nOne more thing to get the table showing up in the admin panel. Make an `admin.py` inside `drinks`:\n\n```python\nfrom django.contrib import admin\n\nfrom .models import Drink\n\nadmin.site.register(Drink)\n```\n\nThe dot in `.models` refers to the same directory.\n\nThis requires a restart of the server, so kill it with Ctrl-C and run `python manage.py runserver` again. Refresh the admin page and there's our drinks table.\n\nYou don't have to use the admin site at all. If you don't think it's helpful you can skip the `admin.py` and the super user entirely. For my sake I think it's worth it.\n\nAdd a couple of rows through the admin so we have something to read: `grape soda` / `very grapey`, and `orange soda` / `very orangey`.\n\nThey show up as \"Drink object (1)\" and \"Drink object (2)\", which is not super useful. You can change how an object gets represented by adding a `__str__` method to the model:\n\n```python\nfrom django.db import models\n\n\nclass Drink(models.Model):\n name = models.CharField(max_length=200)\n description = models.CharField(max_length=500)\n\n def __str__(self):\n return self.name + ' ' + self.description\n```\n\n`self` is how you create a method on the drink object, and all this has to do is return a string. Refresh and you get a bit more detail.\n\n## Start REST framework\n\nWe have a model and some data in the database. Now let's get it out through an API.\n\nWe already installed Django REST framework but it needs added to the installed apps too:\n\n```python\nINSTALLED_APPS = [\n 'django.contrib.admin',\n 'django.contrib.auth',\n 'django.contrib.contenttypes',\n 'django.contrib.sessions',\n 'django.contrib.messages',\n 'django.contrib.staticfiles',\n 'drinks',\n 'rest_framework',\n]\n```\n\n## Create our serializer\n\nA **serializer** describes the process of going from a Python object to JSON. The structure we want back looks like this:\n\n```json\n{\n \"id\": 1,\n \"name\": \"grape soda\",\n \"description\": \"very grapey\"\n}\n```\n\nThat's what the serializer class is for. New file, `drinks/serializers.py`:\n\n```python\nfrom rest_framework import serializers\n\nfrom .models import Drink\n\n\nclass DrinkSerializer(serializers.ModelSerializer):\n class Meta:\n model = Drink\n fields = ['id', 'name', 'description']\n```\n\n`ModelSerializer`, such a difficult word to say.\n\nThe inner `Meta` class is the metadata describing the model. `model` is the class we're serializing, and `fields` is the list of what gets included. `id` is added to the model automatically by Django, so we get it for free.\n\nMore on what else you can do in here: [Serializers - Django REST framework](https://www.django-rest-framework.org/api-guide/serializers/).\n\n## Create our view endpoints\n\nWe have a model, we have a serializer, now we need an endpoint. An **endpoint** being a certain URL you can access data from.\n\nNew file, `drinks/views.py`:\n\n```python\nfrom django.http import JsonResponse\n\nfrom .models import Drink\nfrom .serializers import DrinkSerializer\n\n\ndef drink_list(request):\n drinks = Drink.objects.all()\n serializer = DrinkSerializer(drinks, many=True)\n return JsonResponse(serializer.data, safe=False)\n```\n\nThree steps in that function. Get all the drinks, serialize them, return JSON.\n\n`Drink.objects.all()` gets everything. `DrinkSerializer(drinks, many=True)` handles a list instead of a single object, which is what `many` is for. Then `JsonResponse` sends `serializer.data` back.\n\nThe `safe=False` is there because if you leave it off you get this:\n\n```\nIn order to allow non-dict objects to be serialized set the safe parameter to False.\n```\n\nNow we need to say what URL hits this view, and that's `urls.py` in the project directory:\n\n```python\nfrom django.contrib import admin\nfrom django.urls import path\n\nfrom drinks import views\n\nurlpatterns = [\n path('admin/', admin.site.urls),\n path('drinks/', views.drink_list),\n]\n```\n\nVisit [http://127.0.0.1:8000/drinks/](http://127.0.0.1:8000/drinks/) and there's our list of data.\n\nIf you'd rather have an object than a bare list, throw the serializer data in a dictionary:\n\n```python\nreturn JsonResponse({'drinks': serializer.data})\n```\n\nNow you get an object with a `drinks` attribute holding the list, and since it's a dictionary again you don't need `safe=False` anymore. That's generally how I prefer to return data, but either one works.\n\nCongratulations, at this point you have a working API. It's pretty limited, all you can do is get a list, but it works.\n\n## CRUD\n\nThis whole process is called **CRUD**: create, read, update, delete. Right now we have the read. We still need the C, the U, and the D.\n\nBefore we build the other endpoints, a quick word for anybody who's new. That function takes a GET request. When you literally just put the URL in your browser, you're getting data, that's why it's called GET. Don't overthink it.\n\nYou can see it yourself if you open Inspect and go to the Network tab, then refresh. The request method is `GET`, there's the URL, there's the response.\n\nThe other methods we need are POST, PUT, and DELETE. And a single function can take more than one of them. To do that we use a **decorator**, which is something you put above a function to describe its functionality in some way:\n\n```python\nfrom rest_framework.decorators import api_view\n\n\n@api_view(['GET', 'POST'])\ndef drink_list(request):\n if request.method == 'GET':\n ...\n```\n\nNote the methods go in as a list, one argument, not several.\n\nDon't feel like you have to have all of this memorized. I was referring to the [Django REST framework docs](https://www.django-rest-framework.org/tutorial/quickstart/) the whole time I built this, mostly to get the imports right.\n\n> [!tip]\n> If VS Code says the `rest_framework` import cannot be resolved even though you installed it, it's probably the interpreter. Cmd-Shift-P (Ctrl-Shift-P on Windows), type \"Select Interpreter\", and pick your virtual environment. The dependencies are all inside `.venv`, so you have to point the editor at it instead of your global install. It's just the lens VS Code uses to see what you have installed, things would likely run fine either way.\n\n## POST request\n\nAdding a drink is the same process as reading one, just in the opposite order. We take the data they sent us, deserialize it, and create a drink out of it.\n\n```python\nfrom rest_framework import status\nfrom rest_framework.response import Response\n\n\n@api_view(['GET', 'POST'])\ndef drink_list(request):\n if request.method == 'GET':\n drinks = Drink.objects.all()\n serializer = DrinkSerializer(drinks, many=True)\n return JsonResponse({'drinks': serializer.data})\n\n if request.method == 'POST':\n serializer = DrinkSerializer(data=request.data)\n if serializer.is_valid():\n serializer.save()\n return Response(serializer.data, status=status.HTTP_201_CREATED)\n```\n\nInstead of passing in objects we already have, the data comes off the request with `data=request.data`. Then `serializer.is_valid()` checks what they sent, `serializer.save()` writes it, and we hand back the data with a 201.\n\nWatch out for the autocomplete on those imports, the light bulb suggests a few and none of them were the ones I wanted. Write them out yourself:\n\n```python\nfrom rest_framework.response import Response\nfrom rest_framework import status\n```\n\nNow test it. I use [Postman](https://www.postman.com/) for this. Set the method to POST, go to the body, pick raw, change the type to JSON, and send:\n\n```json\n{\n \"name\": \"strawberry soda\",\n \"description\": \"very good\"\n}\n```\n\nYou don't send an `id`, that gets done automatically.\n\nIf you get a runtime error complaining about the slash in the URL, check `urls.py` against what you typed. Our path is `drinks/` with the trailing slash and the URL I sent to was missing it. Add the slash and send again, and it comes back with an `id` on it, because we hand the data back in the response after it's been saved.\n\nTwo ways to confirm it landed. Get the drinks again and you'll see three of them, or open the admin page and look at the table.\n\n## Drink details - GET\n\nGetting details on one item is a pretty important part of an API. You go to `/drinks/1` and get just that drink back.\n\nFirst a new path in `urls.py`. Same `drinks` prefix, but with a parameter of type `int`:\n\n```python\nurlpatterns = [\n path('admin/', admin.site.urls),\n path('drinks/', views.drink_list),\n path('drinks/', views.drink_detail),\n]\n```\n\nWhatever value is in that spot in the URL gets passed to the view as the `id` argument.\n\nNow the view. We're going to do it a little differently than the list, because there's a better way. Up in `drink_list` we used `JsonResponse`, but `Response` comes from Django REST framework and it's the preferred way to do things, since it can return JSON or HTML depending on who's asking.\n\n```python\n@api_view(['GET', 'PUT', 'DELETE'])\ndef drink_detail(request, id):\n try:\n drink = Drink.objects.get(pk=id)\n except Drink.DoesNotExist:\n return Response(status=status.HTTP_404_NOT_FOUND)\n\n if request.method == 'GET':\n serializer = DrinkSerializer(drink)\n return Response(serializer.data)\n```\n\n`Drink.objects.get(pk=id)` looks it up by primary key, and it throws if there's nothing there, so we wrap it in a try and catch `Drink.DoesNotExist`. Everything in `status` is spelled out for you, `HTTP_404_NOT_FOUND` being the one we want here.\n\nTwo lines is all the GET takes. Try it with `1`, `2`, `3`, then try `4` and you get the 404.\n\nDo the same thing in the browser and you get the browsable HTML view, which is kind of cool. It's similar to the admin panel except it's on the front end, it doesn't require a login, and you can't see everything in the database through it.\n\n## Drink details - PUT\n\nPUT is for updating, and the process is close to the POST we already wrote.\n\n```python\n elif request.method == 'PUT':\n serializer = DrinkSerializer(drink, data=request.data)\n if serializer.is_valid():\n serializer.save()\n return Response(serializer.data)\n return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)\n```\n\nThe difference from POST is that first argument. We pass in the `drink` we already looked up, so the serializer knows it's editing that row rather than making a new one, plus the incoming data.\n\nTest it in Postman by getting drink 3, then switching to PUT and changing the body:\n\n```json\n{\n \"name\": \"soda edited\",\n \"description\": \"very good\"\n}\n```\n\nSend it and you get the new data back. Get it again and the change has persisted.\n\n## Drink details - DELETE\n\nDelete is super easy. We already have a reference to the drink object:\n\n```python\n elif request.method == 'DELETE':\n drink.delete()\n return Response(status=status.HTTP_204_NO_CONTENT)\n```\n\n`drink.delete()` is just the typical way of doing it in Django. Then a 204, which means it worked and there's nothing to send back.\n\nIn Postman, set the method to DELETE, use the id of 3, and clear out the body since we don't need one. You get nothing back, and when you try to GET that drink it's gone.\n\n### Switching the list over to Response\n\nNow that we've seen how much nicer `Response` is, let's take that behavior back up to `drink_list`:\n\n```python\n if request.method == 'GET':\n drinks = Drink.objects.all()\n serializer = DrinkSerializer(drinks, many=True)\n return Response(serializer.data)\n```\n\nStill works in Postman, and now the browser gives us the HTML view for the whole list too. You can even edit data right from that page. Go to `/drinks/1`, put an object in the box, hit PUT, and it updates.\n\nSo we've now got three different ways of working with this data. The admin panel, which doesn't actually use the API, and then for the API itself the browsable HTML page or a tool like Postman.\n\n## Getting JSON through browser\n\nYou might just want plain JSON in the browser instead of that HTML view. Stick `.json` on the end of the URL and it doesn't work yet.\n\nThe fix is building that capability in to our URLs, so we don't just serve those paths but those paths with different extensions:\n\n```python\nfrom rest_framework.urlpatterns import format_suffix_patterns\n\nurlpatterns = [\n path('admin/', admin.site.urls),\n path('drinks/', views.drink_list),\n path('drinks/', views.drink_detail),\n]\n\nurlpatterns = format_suffix_patterns(urlpatterns)\n```\n\nWhatever `format_suffix_patterns` returns replaces the `urlpatterns` variable.\n\nReload and you get an unexpected keyword argument `format`. The quick fix is a parameter on the views:\n\n```python\n@api_view(['GET', 'POST'])\ndef drink_list(request, format=None):\n ...\n\n\n@api_view(['GET', 'PUT', 'DELETE'])\ndef drink_detail(request, id, format=None):\n ...\n```\n\nNow [http://127.0.0.1:8000/drinks/1.json](http://127.0.0.1:8000/drinks/1.json) gives you the JSON, same as you'd get from Postman, and dropping the `.json` puts you back in the HTML view. The full rules for this are in [Format suffixes - Django REST framework](https://www.django-rest-framework.org/api-guide/format-suffixes/).\n\n## Consuming the API\n\nI don't want to build a whole full stack app in this video, but I do want to show what consuming the API looks like, so we'll do a very simple request through Python and leave the rest open for future research.\n\nLeave the server running, because we still need it. Then in a new file in the main directory, `consume.py`.\n\nIn a new terminal tab (with the virtual environment activated):\n\n```bash\npip install requests\n```\n\n[requests](https://requests.readthedocs.io/en/latest/) is a module that makes really simple requests to pages on the internet.\n\n```python\nimport requests\n\nresponse = requests.get('http://127.0.0.1:8000/drinks/')\nprint(response.json())\n```\n\nRun it with `python consume.py`.\n\nIf you get a `No connection adapters were found` error, you left off the protocol, it needs the `http://` on the front.\n\nAnd that's it, we get our data in a Python application. Literally three lines of code.\n\nWe did a ton in this one and it's a lot to learn. I had to reference the documentation constantly while building it, especially for all the different imports, so don't feel like you have to be perfect from day one. Maybe by day two or three, but until then you're okay to make a few mistakes.",[],[],"c56d98a5-7717-4e4e-82e1-1b289deed73d",2439,"django-rest-framework-build-an-api-from-scratch","DeepSeek Harness - Full Tutorial for Beginners",29,"## Timestamps\n\n- `00:00` - intro\n- `02:46` - Getting Started\n- `03:50` - Getting an API Key\n- `05:08` - Setting up a Workspace\n- `06:36` - First Prompt\n- `07:47` - Important Config\n- `10:26` - Initialize our Project\n- `11:45` - Creating a Vault\n- `15:03` - Creating Skills\n- `18:05` - Deterministic Behavior\n- `20:05` - Permissions and Plugins\n- `27:54` - Create a Detailed Spec\n- `34:26` - Deepseek Harness Subagents\n- `35:39` - Reviewing our Spec\n- `37:06` - Working with other Models\n- `38:31` - Local Models\n- `41:51` - Different Provider Subagents\n- `43:23` - Project Review\n\nDeepSeek Harness is a potential alternative to things like Claude Code or Codex. Whenever you hear the term **harness** when it comes to LLMs, that is the software written around the LLM for you to interact with it. The model is the LLM, and the harness is what wraps everything around it: the tools, the chat, the history, all of that.\n\nSo when you're running the DeepSeek software, that's not the LLM itself. And the fact that it's a general harness means we can run pretty much any model from it, DeepSeek's own models, Claude, ChatGPT, or local models through Ollama (which lets you follow along completely free). We'll get all of that set up in this lesson, plus skills, subagents, a vault for your project, permissions and hooks, and a spec-driven build to tie it all together.\n\n## Getting Started\n\nYou can find DeepSeek Harness at [https://deepseek.com](https://deepseek.com). At the time of this recording this is a very new thing, but I'll try to teach it in a way that holds up even as it changes.\n\nYou can go to the GitHub to see the latest version of everything (wildly popular right now with 127,000 stars, and it's open source with an MIT license). But you don't have to go through GitHub, you can just install with the quick start command from their page:\n\n```bash\nnpx @deepseek-ai/dsh web\n```\n\nThe version I got had an RC on the end, release candidate, so some of the little details might change as that version goes up. If you get an error about `npx` not being a thing, you'll need to install Node first from [https://nodejs.org](https://nodejs.org).\n\nThe way this works is it's a web interface. For me it created it on port 3080, so you can copy that URL or command-click it. DeepSeek is a Chinese company, so you might occasionally see a \"translate to English\" prompt in your browser.\n\n> [!tip]\n> DeepSeek Harness 0.1 \"remains in testing for harness developers\" as I record this, and a few things are a little wonky. I remember using Google Antigravity the first week it was released, and the agent manager had some kind of memory leak and would eventually just stop working. That's just part of getting early software, these things get fixed pretty quickly.\n\n## Getting an API Key\n\nOn first launch it asks for an API key, and it's not super clear which API key it wants (there's a configure later option). What we'll do is get a DeepSeek API key from their platform. Go to the DeepSeek platform, create an account, then API keys, create a new key, and copy the value. It won't be visible again, so make sure you capture it.\n\nIt's worth noting this sends your messages to DeepSeek's API platform, it's not running on your local computer. For many of you that's fine, but I wanted to call it out since local models are an option later in this lesson, and in that situation everything stays on your machine.\n\nThe very first prompt you send will probably give you an error saying you don't have any credits. Go back in to the platform, top up, and make a payment. This is not a subscription like you might get with ChatGPT or Claude, it's very similar to the OpenAI or Anthropic API platforms where you pay for credits as you go. I just put in $2 to get something going, and if you want to keep experimenting cheap you can use a cheaper model or off-peak rates (running things at certain times of the day). Once you have credits you can go to usage and see the cost as you go.\n\n## Setting up a Workspace\n\nNext it has you select a workspace. This is just a directory on your computer that you'll be working from. You can create a dedicated folder for following along, I made one called `DSH` and chose that.\n\n## First Prompt\n\nNow write whatever message you want. This is where you'll discover the first bug: for me, only the first character of my message was showing in the prompt box. It still picked up the full message, but I found it works a whole lot better in Safari, so I switched over and the prompt window stopped doing weird things.\n\nI do like the way it shows the steps of a response:\n\n- **Context injection**, which sounds a little scary but is just the context for the chat: the system prompt, any rules, basically the stage-setting for the conversation\n- The **skill catalog**, which describes how to discover skills (empty for us so far)\n- The **think**, the pre-message before the actual response\n- Then the response itself\n\n## Important Config\n\nBefore the fun stuff, a few settings worth understanding.\n\nFirst, access levels: read only, workspace write, or full access. Read only is what it sounds like. The dif between workspace write and full access is basically the ability to read and write outside of the workspace folder you opened. If I wanted it working with files outside this folder, I'd change it to full access.\n\nNext, the model and effort. The default model is flash, a good one to get started with, and you can go pro if you're doing something heavier. Effort is either high or max, which is kinda funny, there's no option for low effort. We'll do high.\n\nThe other major setting shows up when you create a new session: the mode. There's standard mode, code mode, minimal mode, and creator mode. To keep things simple you can start off with **standard mode**, and that's what we'll use.\n\n**Code mode** is pretty interesting though. It basically takes what would be a bunch of back and forth executions in standard mode and writes it as a single TypeScript program that can run as one file. You'd probably go for this option if you're doing something very repetitive across multiple files, condensing all of those round trips in to a single executable. Haven't tried that out yet, so I'm curious to see how it goes.\n\n**Minimal mode** is a two tool coding agent with persistent bash and a string replace editor. Literally that's all it is, no web search or any kind of fancy features. I'm not entirely sure when we would want that, but you at least know it's there if someone's talking about it. And **creator mode** is like a layer up, for working on the infrastructure itself, so plugins and that kind of thing. It might come up later if I'm working on my actual workflows and not just some specific code files.\n\n## Initialize our Project\n\nRight now we're in an empty workspace. What you'll typically do is create the git files to track changes, a `.gitignore` for stuff you don't want in the repository, and an `AGENTS.md`, basically the equivalent of a `CLAUDE.md` if you're coming from Claude. It describes the project and the things the agent should or should not do. It doesn't enforce anything, it just means the agent doesn't come in blind every time it starts working on your project.\n\nSo I just said:\n\n```\ncreate an agents md\n```\n\nVery vague, but it came up with a basic outline with a bunch of to-dos and slots to fill in as we go. I opened Visual Studio Code alongside so I could follow the file changes.\n\n> [!tip]\n> DeepSeek Harness can read a `CLAUDE.md`. So if you're coming from another project and want to test DeepSeek on it, it should pick up all of your existing instructions and execute pretty similarly.\n\n## Creating a Vault\n\nWe're going to create a folder called `vault`, and inside of it a `spec.md`. You can structure the vault however you want. I'm keeping it to a single spec for this example project, but on a complex project I might split it up: a file for auth, one for data, security, the different interfaces or sections of the app.\n\nThen what I'd recommend is getting [Obsidian](https://obsidian.md). You can absolutely work in code, right-click a markdown file and open preview, split the panes, that works. I just think Obsidian gives a better experience. Open vault, open folder as vault, select our `vault` folder, and now you can edit the spec in line with a nice preview.\n\nI started the spec with an author note section where I define what I want, and then the LLM can build out the spec from it. If you're just getting started you don't have to use a spec, but I think it gets much better results, because you can work on the spec almost like a separate thing: read through it, make sure it's what you want, then let the agent go do the thing. You don't have to check in with it every two seconds and direct it as it goes.\n\nThe project itself is really not the focus of this video, so it's a simple one: an app that displays buttons for our favorite websites in the browser, click one and it launches in a new tab. Kind of a visual homepage dashboard.\n\nI also wanted a README to describe the project (that's different from everything we've created so far, it's what shows up on the GitHub homepage). So the prompt was along the lines of:\n\n```\nCreate a readme describing the project. Create a repo and add our vault, the empty spec, the agents.md, and the readme.\n```\n\nIt went through, created files, committed, and then asked a question about the hidden `.obsidian` directory it did not commit, offering to add it to the `.gitignore`.\n\nAt this point you should be able to go back to the platform and see your usage. You can toggle to today and even filter by API key. I'd spent less than a penny across 11 API requests.\n\n## Creating Skills\n\nSkills are basically a way to package up certain behavior in to a keyword we can invoke whenever we need. If you do something very often, create it as a skill with steps the AI follows. A simple one to start with is a skill to commit your files. Yea, I know it's pretty easy to commit files on your own, but we can tie in any checks we need and how we want the commit message structured, ultimately saving time on something very repetitive. Here's the prompt I used:\n\n```\nCreate a skill that will make a commit. Do not share attribution or mention AI, deepseek, etc. Keep a concise bulleted list for the message. Check quickly for anything that shouldn't be committed, but please assume default behavior of committing all working files, not just the ones you've touched. The goal is an empty working directory. Do not push changes or deploy anything.\n```\n\nI said \"quickly\" because it doesn't need a super thorough check on file sizes and types, and I don't want committing to be an elaborate process. It creates the skill and brings it in live, it appears in the session skill catalog immediately. For me the file landed inside the repo in an agents skills folder, just a markdown file that travels with the project.\n\nI like to have the AI create the skill rather than writing it myself, it's pretty thorough: a description, a when-to-use, the numbered steps, some rules at the end. Probably better than I would have done. And skills aren't really anything fancy, these could just be MD files in our vault, because all it does is bring the skill's text in to context.\n\n## Deterministic Behavior\n\nIf you look at the generated skill, it does a \"quick sanity check\" for anything clearly unsafe, secrets, huge binaries, and so forth. But most likely it's just reading and interpreting, no formal checks. That's okay for some things, but for many things you'll want an actual script execution so the results are predictable and we're not getting different results for different runs.\n\nSomething that gives the same output for the same input is said to be **deterministic**, and anything that's a nice boolean yes or no is a perfect chance to use a deterministic check. The skill as generated was too much English, not enough code. Fixing that was one message:\n\n```\nPlease convert to deterministic script\n```\n\nIt thought for quite a while on this one and made a lot of changes. It removed model judgment from deciding what's safe and created a `check-commit-safety.sh` script: checks for secrets, a deny list, a large file check at 10 megabytes.\n\nSo let's test it. I created a `.env` with `password=secretpassword` in it and asked for a commit:\n\n```\nI just added a .env, confirm this would be added to a .gitignore on the trigger\n```\n\nIt caught it, and asked me to confirm adding it to the `.gitignore`, which I did. That's an example of creating predictable outcomes from your AI instead of always trusting it to follow the words you tell it. As you've probably experienced, that doesn't always work.\n\n## Permissions and Plugins\n\nIf you've come from Claude Code, it asks permission for every single thing, which is really annoying, and the fixes there are adding things to your permissions, using auto mode (classifies safe vs dangerous), or dangerously skipping all permissions. That's the Claude world.\n\nWithin DeepSeek Harness it's different: it already has permission to do everything inside the workspace without asking. That's nice because you're productive right from the start, but there are definitely risks. Yes, it blocks execution outside the folder, but what about a CLI you can access from anywhere? For example:\n\n```\nuse GitHub CLI to get my GitHub username\n```\n\nIt just ran that bash without complaining or blocking. So there's more risk here than with something that blocks every execution.\n\nThe best protection is removing anything you don't want it able to touch. If you don't want it accessing your GitHub CLI, remove the GitHub CLI. If you don't want it touching your cloud provider CLI, remove that too, and same for databases, remove those connection strings from your local system so there's no way for it to even get that information. If you can't do it yourself, then your LLM can't do it for you. That can be a pain if those are tools you actively use, so the other route is running the whole thing in a container, an isolated environment that can't touch your primary system. Those are two different paths you can explore more on your own. Either way, just don't have access to your production database on your system, don't even make that damage possible.\n\nOn top of that, we can set explicit deny rules. These are not foolproof, see them as a way to guide the LLM and prevent it from doing something stupid on accident, if it's maliciously trying to achieve some goal it might bypass whatever you're blocking. As always, the easiest way is to ask the agent to set it up:\n\n```\ncreate a hook that will prevent you from executing git reset or any destructive behaviors to our repo\n```\n\nWhenever I create these rules I adjust them as I go, if they get too restrictive and constantly annoy me or prevent me from progressing on something, I loosen them up. Just start with something so you have some boundaries and adjust as you need.\n\nA couple of interesting things happened here. First, it started trying to create a git shim that would prevent certain commands, not what I wanted. I don't believe DeepSeek Harness has the same formal hook structure Claude Code has, but it does have the ability to guard tool execution. Second, we got our first approval warning, because the change goes outside the workspace: it wrote in to a DSH folder in my home directory. It created this as a **plugin** wired in to my live profile, added instructions to `AGENTS.md`, and said it needs restarted before taking effect.\n\nThis is a good spot for clarifying questions, which I'd put in the README for anyone setting up the project:\n\n```\nwhat specifically was created outside of the workspace and what is created inside. If I switch computers, what needs set up?\n```\n\nThe plugin lives outside, everything else travels with the repo. I committed, restarted the server, made a quick test change, then asked for a `git reset --hard`, and it came back with a bash blocked message from the protect hook. So it did work.\n\nThen you can expand it with anything else you don't want possible:\n\n```\nAllow access to local DB only through docker psql and a direct psql is blocked\n```\n\nThat makes sure it's not touching any of the Postgres databases on my system, only executing through Docker, and I only use Docker containers for data I don't care about. I also had it rename the plugin to a general command guard instead of the git-specific name, since one file should do all the blocking.\n\n## Create a Detailed Spec\n\nNow the spec. I wrote mine out in Obsidian, roughly this:\n\n- Database: Postgres container, access through `docker psql` only\n- Goal: list out favorite sites with a nice icon, like a grid of squares\n- CRUD: ability to add new favorites, edit title, description, and photo (default photo, so not required)\n- A square at the end with a plus to add a new bookmark in a modal\n- Single page app, mobile first: two bookmarks per row on small devices, maybe four to six on desktop\n- Sections, with drag and drop from one section to another\n- Button to open all sites from a section as new tabs\n- Dark mode, please\n- Extract any pure logic in to functions we can easily test, keep visual components as dumb as possible\n- Spec will have two checkboxes per capability: one for implementation, one for a separate verifier's check\n- Subagents: a verifier, plus a mobile verifier using Chromium to confirm visuals and UX\n\nIf I was building a really thorough subagent orchestration I'd go in to much more detail on what each agent does, and I'd have the AI help define them, which is exactly what we do next:\n\n```\nLook at the spec now. Please refine the sub agents. Keep it simple. Commit first. First evaluate anything we need that is missing. Don't write out the full spec quite yet.\n```\n\nIt read the spec and came back with clarifying questions. The verifier it proposed runs the pure function unit tests, boots the API and checks every endpoint contract, checks database state directly via `docker exec` psql, and reports pass or fail. You could create more elaborate integration tests, but I'm fine with that for now. The UI verifier looks at the thing and makes sure it looks like a thing, and the main agent spawns both and triages their reports.\n\nIt also asked about the stack (I went with its recommended route), whether images should be uploads or URLs (URLs, keeping it simple), and how drag and drop should be implemented. Then it listed its assumptions, which is your chance to interrupt. I changed one: put Postgres on 5436 so it doesn't conflict with anything else I have running.\n\nOne more instruction I added, because I was worried about it improvising:\n\n```\nDon't do complex workarounds. If you're missing playwright, for example, don't just ignore it. Just install what you need, so we know the result is good.\n```\n\nThen I had it write the full spec and be as thorough as possible, thorough enough that general subagents could implement it. You could even use cheaper agents for that. This is a common thing I'll do: a more expensive model for the conversation, the spec, and the planning, then delegate the work to cheaper agents, because their output is easily verified against the spec.\n\nBasically, spend a lot of time on the spec because it's going to make your life a whole lot easier.\n\n## DeepSeek Harness Subagents\n\nThe way subagents work in DeepSeek Harness is through a subagent tool. You can see it with something silly:\n\n```\ncreate five sub agents that all have to wait 60 seconds\n```\n\nYou'll see the tool called five times, the subagents run in the background, and you can click in to any one of them to see its input and what it's doing. Each one has its own token usage, so there is a cost. But there's also a lot of benefit: your main chat keeps a much cleaner context window, focused on what it's focusing on, which probably gets better results using fewer tokens. So it costs, but it also saves you, if that makes any sense at all.\n\nWhen a subagent finishes, it reports back to the invoker, the main agent.\n\n## Reviewing our Spec\n\nThe written spec came back with all the technology, prerequisites, the repository structure, the env, a Docker compose for the database, the commands needed, the data model from Prisma, all the API endpoints (not too many of them), a response shape, and front-end behavior, the actual action items a user can do, which is more what I was thinking of with a spec. This is doing a lot.\n\nIt also called out concerns before starting, specifically opening all tabs from a section (browsers block that) and favicon retrieval. Worth reading those and updating the spec if you want different behavior. Then:\n\n```\ncommit then implement with sub agents\n```\n\nWhile it ran I checked usage, still had about $1.58 left. So I let it go and moved on to other models.\n\n## Working with other Models\n\nWithin settings you can go to models, and you can add a provider or a custom provider. There's a ton of options in the provider list. I went with Anthropic, created an API key over on the Anthropic side (named it DSH so I know what it's for), and pasted it in.\n\nNow in a new session you can drop down and switch the model over to any of the Claude models. I don't know why 4.5 was showing as the latest when Opus 5 is right there, but I said hello, got a response, and watched a couple cents disappear from my Claude credits. There's a cost to any conversation since it reads the AGENTS.md and everything else, plus Opus is a more expensive model.\n\n## Local Models\n\nWe're not limited to paid models. For local models we'll use [Ollama](https://ollama.com), which gives you a way to run models from your own computer. On Mac:\n\n```bash\nbrew install ollama\nbrew services start ollama\n```\n\n(on Windows, just install it from the web page). Now in a browser visit `localhost:11434/v1/models` and you'll get a list of the models available to you.\n\nThere's a ton of models you can pull, the full list is on ollama.com. I searched for Qwen, a pretty popular one, and there's a bunch of different parameter sizes. If you're on a weaker system you might want to go for some of the smaller ones. The flagship Qwen right now is very large, 18 GB, and requires a lot of memory, so probably not recommended for most if you're just using it for daily use, but that's what I went with, plus a regular Qwen 3 which is only about 5 GB:\n\n```bash\nollama pull qwen3.8:27b\nollama pull qwen3\n```\n\nThen within DeepSeek Harness, go to models and add a custom provider:\n\n- Name it whatever, I said ollama\n- Base URL is that same localhost URL without the `/models` at the end: `http://localhost:11434/v1`\n- OpenAI completions is fine for the API format\n- Leave the API key empty\n- Add a model\n\nA couple of gotchas I hit:\n\n- It complained about no API key for the provider, even though Ollama doesn't need one. Just edit the provider and put in a placeholder, I put an `x`.\n- I got a 404 on the model. `ollama list` in the terminal shows both names and IDs, and I'd grabbed the ID. It actually wants the name, so replace it with the name.\n\nAfter that, I asked it to describe the repo, and it was working, but taking so freaking long that I eventually stopped it and gave Qwen 3 something simpler, 5 + 5. After a minute and 14 seconds it was able to conclude that 5 + 5 is 10. So yea, probably not how I would do agentic coding. But if you had some ongoing task to run overnight, a local model might do just fine. An example that comes to mind: generating embeddings for data you want to use for RAG. Kick it off overnight and you don't sit waiting on the result, and it costs nothing.\n\n## Different Provider Subagents\n\nBack in the main chat, a quick experiment:\n\n```\nCreate two sub agents both waiting 1 minute. One using opus, one using qwen 3.\n```\n\nIt recommended a workflow tool with model overrides, which lets you pin a child agent to a specific LLM. And it worked, one subagent under Opus, one under Qwen, both just waiting and doing nothing, but you get the idea. Running subagents across different models from different providers is a pretty interesting idea. That's something I might need to explore in a dedicated lesson, I don't think I can give it the full attention it needs right here.\n\n## Project Review\n\nBack to our original session: the favorite websites app is built, verified, and committed. The full spec, build, verify pipeline ran end to end as a single long-running autonomous run with background subagents, and it reported what was done, how it was verified, and the concrete results.\n\nSo let's use it. I added a site, and it pulled the most ugly favicon on planet Earth, so I edited it and pasted an image URL instead, a whole lot better (remember, we chose URLs over uploads). Added my YouTube channel. Created a news section and dragged a bookmark over, the drag and drop is a little wonky, that's something I'd get some dedicated back and forth with the agents on, but for a first run this ain't too bad. The light mode, dark mode toggle works. The open-all button opened one tab instead of both, which was one of the concerns it flagged before we even started, so I'm not surprised. And everything persists across a refresh since it's all in our local database. Pretty neat.\n\nThat's your introduction to DeepSeek Harness. It's a platform designed to be driven a lot by plugins, and there are already thousands of them, which is crazy considering how new the software is. This is literally a never-ending topic, so let me know if there's anything specific you'd like covered in an upcoming lesson.",[],[],"ecdc608f-b61c-4687-83e4-31dfd0eda59a",2755,"deepseek-harness-full-tutorial-for-beginners","Biggest Mistakes of Software Engineers (Avoid these if you want to succeed)",28,1208,"biggest-mistakes-of-software-engineers-avoid-these-if-you-want-to-succeed","API Design and Architecture - Backend Engineering Intro (1 Hour)",27,3102,"api-design-and-architecture-backend-engineering-intro-1-hour","API Status Codes and OpenAPI Documentation - Backend Engineering",26,1599,"api-status-codes-and-openapi-documentation-backend-engineering","FastAPI Intro - Full CRUD REST API Tutorial (1 HOUR) - Backend Engineering",25,"## Timestamps\n\n- `00:00:00` - Intro\n- `00:00:41` - What is FastAPI?\n- `00:01:58` - Getting Started\n- `00:03:55` - Building an API\n- `00:11:09` - Paths and Path Parameters\n- `00:13:34` - GET Requests\n- `00:15:44` - Mock data with dictionary\n- `00:18:59` - How to get a single campaign\n- `00:21:22` - Interacting with the API\n- `00:26:36` - Mocked POST, PUT, DELETE\n- `00:33:19` - Working with a Database\n- `00:34:34` - SQL Databases\n- `00:37:53` - GET multiple\n- `00:40:11` - Lifespan Events\n- `00:43:18` - Building the type\n- `00:47:19` - Seeding the Database\n- `00:49:47` - GET\n- `00:51:17` - Types\n- `00:53:09` - GET BY ID\n- `00:54:50` - Generic Response Type\n- `00:59:14` - POST - Creating data\n- `01:02:40` - Custom create type\n- `01:05:30` - PUT - Updating Data\n- `01:06:52` - Retrieve data\n- `01:08:54` - DELETE - Remove data\n- `01:10:17` - Outro\n\nFastAPI is one of a few popular frameworks for web development in Python. The other two you'll hear about are Django and Flask, and I've done videos on both of those as well.\n\nThis one is hands on the whole way through. We build a CRUD API from an empty directory to full create, read, update, delete against a SQLite database.\n\nIf you want the concepts first, the prerequisite is [API Design and Full Introduction](https://app.coursecatalyst.com/products/63765398-fb1e?lesson=8151cce6-d15d). We are not going to assume much previous HANDS ON experience, but I do recommend you understand the major API concepts.\n\nThe repo for this lesson: [https://github.com/CalebCurry/fastapi-example](https://github.com/CalebCurry/fastapi-example)\n\n## What is FastAPI?\n\nFastAPI is the framework that gives us a lot of tools to build applications. Specifically focused on building the backend. The frontend displays the data while the backend provides the data. This data will be stored in a database.\n\nThis data is given in a predictable way, JSON provided by an API. An API allows you to request information and receive it in JSON.\n\nIt's fast, but the bigger thing is that it's fast to CODE. By the end of this you will have an API that adheres to the OpenAPI spec, with the documentation generated for you, which makes consuming the API so much easier. The docs will state the types and the structure the client should use, and that structure gets enforced on the backend.\n\nThat enforcement comes from Pydantic, the most widely used data validation library for Python, which FastAPI is built with. It's also built on Starlette, which is what gives you the async web service underneath.\n\nThis is probably my favorite feature. I built a Rust API and had to build all this documentation out manually. It wasn't that difficult, you can just write the OpenAPI JSON files by hand even, but the library I was using was supposed to make it easier and it was still much more work than doing it with FastAPI.\n\n## Getting Started\n\nI'm going to build a project called `omnicopy`. The idea is an app that helps with copywriting content for marketing campaigns. You write some copy, then you want it distributed across social media, a newsletter, the website, basically have it in all locations. You can follow along exactly or come up with your own folder name.\n\nI'm running this from a Mac. If you're on Windows you can follow along too, but a couple of the commands will differ (the venv activate one especially), or you can run WSL.\n\n```bash\nmkdir omnicopy\ncd omnicopy\npython3 -m venv .venv\n. .venv/bin/activate\necho \".venv\" > .gitignore\npip install --upgrade pip\npip install \"fastapi[standard]\"\npip freeze > requirements.txt\ngit init\ngit add .\ngit commit -m \"initial commit\"\ntouch main.py\n```\n\nThe `[standard]` in quotes is you picking which optional features get installed. The `pip freeze` gives you a `requirements.txt` so you can recreate this virtual environment later on another machine.\n\nOn Windows the activate line is something like `.venv\\Scripts\\activate` instead, look up the exact command for your shell.\n\nNow open your editor:\n\n```bash\ncode .\n```\n\nI'd switch to the VSCode terminal but be sure to reactivate your virtual environment. Mine activates it automatically, yours may not, and you'll see `.venv` show up on the left when it's active.\n\n```bash\n. .venv/bin/activate\n```\n\n```python\nfrom fastapi import FastAPI\n\napp = FastAPI()\n\n\n@app.get(\"/\")\nasync def root():\n return {\"message\": \"Hello World\"}\n```\n\n> [!tip]\n> For Language Server support / proper error messages you can install Pylance in VSCode, and set your user settings with `\"python.analysis.typeCheckingMode\": \"strict\"`\n> You may need to reset VSCode.\n\nRun the project:\n\n```bash\nfastapi dev main.py\n```\n\nYou can now visit [http://127.0.0.1:8000](http://127.0.0.1:8000) or [http://127.0.0.1:8000/docs](http://127.0.0.1:8000/docs) for the API documentation.\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/hzQBKRZiFGRR.png)\n\nThis is swagger, which reads from an openapi.json file. You can find that at [http://127.0.0.1:8000/openapi.json](http://127.0.0.1:8000/openapi.json).\n\nOpenAPI and swagger are closely related but slightly different. OpenAPI is the actual spec, the structure describing your API. Swagger is a suite of open source tools that implement and work with that spec, and the page you're looking at is one of them.\n\nQuick summary of info so far. We create an instance of the FastAPI class. We define a **path operation function**. We associate it with a particular HTTP method (FastAPI calls these **path operations**) using a decorator.\n\n```python\n@app.get(\"/\")\nasync def root():\n```\n\nOperation in OpenAPI and FastAPI refer to the HTTP methods. So for every method and every path, we're going to have a function that handles that request.\n\nThese functions are defined async. [Concurrency and async / await - FastAPI](https://fastapi.tiangolo.com/async/#in-a-hurry)\n\n### App Idea\n\nA marketing campaign will consist of many pieces, like content pieces, social media posts, newsletters, blog posts, etc. So we will build this up, but our basic data starting structure will be something like:\n\n```python\nCampaigns\n- campaign_id\n- name\n- due_date\n- created_at\n\npieces\n- piece_id\n- campaign_id\n- name\n- content\n- content_type\n- created_at\n```\n\nA piece relies on a campaign existing first, so in this video we ONLY worry about campaigns. Relationships between the two come in a later lesson.\n\nWorth noting on the naming: `created_at` is generated by the backend or the database, while `due_date` is set by the user. I end the automatic timestamp stuff with `at` so you can tell them apart at a glance. And `campaign_id` versus just `id` is a toss-up, I've grown to like the table name prefixing the ID because I think it makes joins easier, but plain `id` is fine too. [Naming primary keys \"id\" vs \"something_id\" in SQL](https://stackoverflow.com/questions/10436953/naming-primary-keys-id-vs-something-id-in-sql)\n\n## Building an API\n\nWe will build up to a fully functional API.\n\n### Paths and Path Parameters\n\nEvery endpoint is going to start with `/api/v1`, and repeating that on every decorator gets annoying. So instead we create a `root_path` by providing it as an argument when we instantiate FastAPI, and it gets prepended to each path.\n\nAdditionally, we take a value through the URL. This is called a **path** parameter.\n\n```python\nfrom fastapi import FastAPI\n\napp = FastAPI(root_path=\"/api/v1\")\n\n\n@app.get(\"/\")\nasync def root():\n return {\"message\": \"Hello World\"}\n\n\n@app.get(\"/campaigns/{id}\")\nasync def read_campaign(id: int):\n return {\"id\": id}\n```\n\nThe naming for these functions is typically the action (create, read, update, delete) followed by the resource. So `read_campaigns` for the list and `read_campaign` for one of them.\n\nThe URL to access this new endpoint is [http://127.0.0.1:8000/api/v1/campaigns/5](http://127.0.0.1:8000/api/v1/campaigns/5). Whatever ID you put in here will be given back as a response like an echo.\n\n### GET Requests\n\nJumping directly to working with the database is quite the jump, so first I want to mock the data and get all the endpoints built out. That way the interface to our API is pretty much done, and the next step is just swapping the data layer.\n\n```python\nfrom datetime import datetime\nfrom fastapi import FastAPI, HTTPException\nfrom typing import Any\napp = FastAPI(root_path=\"/api/v1\")\n\n@app.get(\"/\")\nasync def root():\n return {\"message\": \"Hello world!\"}\n\ndata : Any = [\n {\n \"campaign_id\": 1,\n \"name\": \"Summer Launch\",\n \"due_date\": datetime.now(),\n \"created_at\": datetime.now()\n },\n {\n \"campaign_id\": 2,\n \"name\": \"Black Friday\",\n \"due_date\": datetime.now(),\n \"created_at\": datetime.now()\n }\n]\n\n\"\"\"\nCampaigns\n- campaign_id\n- name\n- due_date\n- created_at\n\"\"\"\n\n@app.get(\"/campaigns\")\nasync def read_campaigns():\n return {\"campaigns\": data}\n\n@app.get(\"/campaigns/{id}\")\nasync def read_campaign(id: int):\n for campaign in data:\n if campaign.get(\"campaign_id\") == id:\n return {\"campaign\": campaign}\n raise HTTPException(status_code=404)\n```\n\nFirst, we create an array of mock data. Dictionaries will be used as this converts directly to JSON. I said dictionary out loud and then immediately made it a list of dictionaries, because we're returning multiple campaigns.\n\nPylance is going to complain about the types on that list. Typing `data` as `Any` shuts it up for now, and we circle back to real types once we get to the database.\n\nWe can now visit [http://127.0.0.1:8000/api/v1/campaigns](http://127.0.0.1:8000/api/v1/campaigns)\nas well as [http://127.0.0.1:8000/api/v1/campaigns/2](http://127.0.0.1:8000/api/v1/campaigns/2)\n\n```json\n{\n \"campaign\": {\n \"campaign_id\": 2,\n \"name\": \"Black Friday\",\n \"due_date\": \"2025-08-23T15:10:39.680870\",\n \"created_at\": \"2025-08-23T15:10:39.680870\"\n }\n}\n```\n\nThis will return a 404 if no entry exists with the provided ID.\n\nYou can analyze the request in the network tab of the browser. Do a refresh, click the request, and you'll see the 200 response code, the GET request method, and `application/json` as the response content type.\n\n### Interacting with the API\n\nYou can test requests in the API docs directly, which is very handy. This will give you a starting structure, too. Everything in this video that isn't a plain GET gets done from this page, because you can't fire a POST from the browser URL bar.\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/po3OVMIwTh9I.png)\n\nThat said, I still like to use some other clients, and this is worth knowing even though I don't use it on camera. I recommend Postman or the REST Client extension in Visual Studio Code, which lets you keep the requests as a file in your repo.\n\nFull info can be found here - [marketplace.visualstudio.com](https://marketplace.visualstudio.com/items?itemName=humao.rest-client)\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/voHi3U0NUxSn.png)\n\nWe can create a variable for easy URL reuse:\n\n```\n@base_url=http://localhost:8000/api/v1\n\n{{base_url}}/campaigns\n\n###\n\n{{base_url}}/campaigns/2\n```\n\nThis is handy because we don't have to leave our editor and we can include this in our repo.\n\nAt this point you can jump directly to working with the database, in a real project this is likely what I would do, but for the sake of learning I do believe mocking the POST, PUT and DELETE endpoints is a healthy first step. At that point, you have the API interface defined and you just have to replace the internal implementation to use a database, so we can focus on that separately.\n\n### Mocked POST, PUT, DELETE\n\nHere is the API code for mocked `POST`, `PUT`, and `DELETE`.\n\n```python\nfrom datetime import datetime\nfrom random import randint\nfrom fastapi import FastAPI, HTTPException, Response\nfrom typing import Any\napp = FastAPI(root_path=\"/api/v1\")\n\n@app.get(\"/\")\nasync def root():\n return {\"message\": \"Hello world!\"}\n\ndata : Any = [\n {\n \"campaign_id\": 1,\n \"name\": \"Summer Launch\",\n \"due_date\": datetime.now(),\n \"created_at\": datetime.now()\n },\n {\n \"campaign_id\": 2,\n \"name\": \"Black Friday\",\n \"due_date\": datetime.now(),\n \"created_at\": datetime.now()\n }\n]\n\n@app.get(\"/campaigns\")\nasync def read_campaigns():\n return {\"campaigns\": data}\n\n@app.get(\"/campaigns/{id}\")\nasync def read_campaign(id: int):\n for campaign in data:\n if campaign.get(\"campaign_id\") == id:\n return {\"campaign\": campaign}\n raise HTTPException(status_code=404)\n\n@app.post(\"/campaigns\", status_code=201)\nasync def create_campaign(body: dict[str, Any]):\n\n new : Any = {\n \"campaign_id\": randint(100, 1000),\n \"name\": body.get(\"name\"),\n \"due_date\": body.get(\"due_date\"),\n \"created_at\": datetime.now()\n }\n\n data.append(new)\n return {\"campaign\": new}\n\n@app.put(\"/campaigns/{id}\")\nasync def update_campaign(id: int, body: dict[str, Any]):\n\n for index, campaign in enumerate(data):\n if campaign.get(\"campaign_id\") == id:\n\n updated : Any = {\n \"campaign_id\": id,\n \"name\": body.get(\"name\"),\n \"due_date\": body.get(\"due_date\"),\n \"created_at\": campaign.get(\"created_at\")\n }\n data[index] = updated\n return {\"campaign\": updated}\n raise HTTPException(status_code=404)\n\n\n@app.delete(\"/campaigns/{id}\")\nasync def delete_campaign(id: int):\n\n for index, campaign in enumerate(data):\n if campaign.get(\"campaign_id\") == id:\n data.pop(index)\n return Response(status_code=204)\n raise HTTPException(status_code=404)\n```\n\n> [!tip]\n> In the video I had `update_campaign` and `delete_campaign` swapped on these two decorators and only caught it much later. The code above has them the right way round.\n\nOn the POST, I started out with `request: Request` and `body = await request.json()`. That works, but the docs page won't show a request body field, because FastAPI has no idea a body is coming. Typing the parameter as `body: dict[str, Any]` instead is what tells FastAPI to expect a body, and then the field shows up in the docs.\n\nIf you want a different HTTP code than 200 you can pass an additional `status_code` parameter in the decorator. Otherwise the create will default to 200 (not the end of the world).\n\nSome other things worth calling out:\n\n- This maintains the state until the server is reset. It's all in memory, so a restart puts you back at two campaigns.\n- Updating maintains the same ID, returns 200 with the updated element in the body.\n- For the PUT we deliberately carry the ORIGINAL `created_at` over instead of generating a new one. It's an update, not a new element, and the client shouldn't have to send it.\n- Deleting removes the data but returns a 204 with no body.\n- Current limitation is that we are parsing the body manually and have no concept of typing. This makes the API less clear and limits our API documentation. We will fix that soon.\n\nIf the docs page hands you a 422 back on the PUT, look at your JSON before you look at your Python. I got one from a trailing comma in the request body.\n\nFor reference, here are those same requests as REST Client / `.http` calls:\n\n```\n###\n\n# Create new campaign\nPOST {{base_url}}/campaigns\nContent-Type: application/json\n\n{\n \"name\": \"new campaign\",\n \"due_date\": \"2025-12-25\"\n}\n\n###\n\n# Update campaign\nPUT {{base_url}}/campaigns/2\nContent-Type: application/json\n\n{\n \"name\": \"updated campaign\",\n \"due_date\": \"2026-01-01\"\n}\n\n###\n\n# Delete campaign\nDELETE {{base_url}}/campaigns/2\n\n```\n\nAt this point we have a pretty solid starter interface to working with our data. You can now look at the swagger.\n\n[http://127.0.0.1:8000/docs](http://127.0.0.1:8000/docs)\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/1ZtFAccZS48I.png)\n\nThis would be a pretty good check point if you want to commit your code as the next section will be a bit destructive.\n\n```bash\ngit add .\ngit commit -m \"mocked CRUD\"\n```\n\nI did not add `__pycache__` to the `.gitignore`, which probably would have been smart, but it's not the end of the world.\n\n## Working with a Database\n\nTo talk to the database I'm going to use an ORM, an object relational mapper. This takes database records and converts them to objects in our code, so we can mostly skip writing SQL. ORMs have limitations and challenges, but I think it's a great place to start.\n\nThe two big options are SQLAlchemy and SQLModel. SQLModel is what FastAPI recommends, it's by the same creator, and you can think of it as SQLAlchemy plus Pydantic for the typing. The typing is something I want anyways so that's the route I'm going. There's various debate about which to use, I'm just going with the default recommendation instead of overthinking it. If you do end up switching to SQLAlchemy later, a lot of this transfers, since SQLModel is built on top of it.\n\n[SQL (Relational) Databases - FastAPI](https://fastapi.tiangolo.com/tutorial/sql-databases/)\n\n```bash\npip install sqlmodel\npip freeze > requirements.txt\n```\n\nWe start with SQLite, but it's easy to swap out for another database since that level is abstracted away. If you're on Postgres the only major thing that changes is the connection URL. Don't fret if you're using something else, still follow along with this material.\n\n### GET multiple\n\nAt the top of our file:\n(Much of the DB connection code I am getting directly from the docs).\nThe only thing I changed from the time of this writing is the approach to initializing the database as the example in the docs was deprecated, I instead used lifespan events.\n\n```python\nfrom contextlib import asynccontextmanager\nfrom fastapi import Depends, FastAPI\nfrom datetime import datetime, timezone\nfrom typing import Annotated\nfrom sqlmodel import Field, Session, SQLModel, create_engine, select\n\nfrom pydantic import BaseModel\n\nclass Campaign(SQLModel, table=True):\n campaign_id: int | None = Field(default=None, primary_key=True)\n name: str = Field(index=True)\n due_date: datetime | None = Field(default=None, index=True)\n created_at: datetime = Field(default_factory=lambda: datetime.now(timezone.utc), index=True)\n\n\nsqlite_file_name = \"database.db\"\nsqlite_url = f\"sqlite:///{sqlite_file_name}\"\n\nconnect_args = {\"check_same_thread\": False}\nengine = create_engine(sqlite_url, connect_args=connect_args)\n\n\ndef create_db_and_tables():\n SQLModel.metadata.create_all(engine)\n\n\ndef get_session():\n with Session(engine) as session:\n yield session\n\nSessionDep = Annotated[Session, Depends(get_session)]\n\n@asynccontextmanager\nasync def lifespan(app: FastAPI):\n # Startup: migrate + seed\n create_db_and_tables()\n with Session(engine) as session:\n if not session.exec(select(Campaign)).first():\n session.add_all([\n Campaign(name=\"Summer Launch\", due_date=datetime.now(timezone.utc)),\n Campaign(name=\"Black Friday\", due_date=datetime.now(timezone.utc)),\n ])\n session.commit()\n yield\n\n\napp = FastAPI(root_path=\"/api/v1\", lifespan=lifespan)\n\n\n@app.get(\"/\")\nasync def root():\n return {\"message\": \"Hello World\"}\n\n\nclass CampaignsResponse(BaseModel):\n campaigns: list[Campaign]\n\n@app.get(\"/campaigns\", response_model=CampaignsResponse)\nasync def read_campaigns(session: SessionDep):\n data = session.exec(select(Campaign)).all()\n return {\"campaigns\": data}\n```\n\nThis is a MAJOR change so let's walk through as much as we can.\n\nFirst, the database setup. The engine maintains the connection to the db. This is shared by anyone making a request to the API and is used when working with the database. Setting `check_same_thread` to false allows FastAPI to use the same SQLite database across multiple threads.\n\nSessions then use this engine to do work with the db. The session keeps track of any changes needed in the data and is the thing that actually interacts with the database.\n\n`SessionDep` is a FastAPI dependency with yield, which gives a new session for each request. That's what ensures one session per request, and it means we can pass the session around by just adding a `session: SessionDep` parameter to any route that needs it.\n\nThe function `create_db_and_tables` creates the table, but we only want to do this on app startup, and behind the scenes it won't try to create new stuff if it already exists.\n\n### Lifespan Events\n\nThe way we run that on startup is with this lifespan function. Anything before the `yield` runs on startup and anything after the yield runs on shutdown, so that second half is where you'd release resources. Then you pass `lifespan=lifespan` when you instantiate the app and FastAPI invokes it for you.\n\n[Lifespan Events - FastAPI](https://fastapi.tiangolo.com/advanced/events/#lifespan)\n\nWhen you run this, you should see a `database.db` show up in your files. It gets created in whatever directory you run from. If it doesn't appear, check three things: that you passed `lifespan` to `FastAPI(...)`, that the lifespan function actually calls `create_db_and_tables`, and that `create_db_and_tables` is doing what you think it is.\n\nThe nice part of this is that anytime you mess up, you can just delete `database.db` and it gets recreated.\n\n### Building the type\n\nAnd what tables does it make exactly? It goes off of our model.\n\nOn a normal class this would be a class level variable with a default, however this is the structure used to define columns in the database table. `table=True` is how SQLModel knows this class maps to an actual table, and that matters because we're about to create other types based on `Campaign` that are NOT connected to a table.\n\nThe main thing I want to call out is `default_factory=lambda: datetime.now(timezone.utc)`. This takes a function to use for generating a value each time an object is created, but the function is not invoked immediately with `()`, so for example we could use `datetime.now` (doesn't allow for args), but because I want to provide an argument, we need to use another function, in this case a lambda function. This gets invoked whenever an object is created, which then invokes `datetime.now` passing in `timezone.utc`.\n\nI first wrote that as `default=` and the app blew up. Because it's a callable and not a value, it has to be `default_factory`.\n\nWe can pass `echo=True` to `create_engine` to see the SQL used for this:\n\n```\nCREATE TABLE campaign (\n campaign_id INTEGER NOT NULL,\n name VARCHAR NOT NULL,\n due_date DATE,\n created_at DATETIME NOT NULL,\n PRIMARY KEY (campaign_id)\n)\n\n2025-08-23 23:37:07,818 INFO sqlalchemy.engine.Engine [no key 0.00003s] ()\n2025-08-23 23:37:07,819 INFO sqlalchemy.engine.Engine CREATE INDEX ix_campaign_name ON campaign (name)\n2025-08-23 23:37:07,819 INFO sqlalchemy.engine.Engine [no key 0.00004s] ()\n2025-08-23 23:37:07,819 INFO sqlalchemy.engine.Engine CREATE INDEX ix_campaign_created_at ON campaign (created_at)\n2025-08-23 23:37:07,819 INFO sqlalchemy.engine.Engine [no key 0.00023s] ()\n2025-08-23 23:37:07,819 INFO sqlalchemy.engine.Engine CREATE INDEX ix_campaign_due_date ON campaign (due_date)\n2025-08-23 23:37:07,820 INFO sqlalchemy.engine.Engine [no key 0.00002s] ()\n2025-08-23 23:37:07,820 INFO sqlalchemy.engine.Engine COMMIT\n2025-08-23 23:37:07,820 INFO sqlalchemy.engine.Engine BEGIN (implicit)\n2025-08-23 23:37:07,821 INFO sqlalchemy.engine.Engine SELECT campaign.campaign_id, campaign.name, campaign.due_date, campaign.created_at\nFROM campaign\n2025-08-23 23:37:07,821 INFO sqlalchemy.engine.Engine [generated in 0.00005s] ()\n2025-08-23 23:37:07,822 INFO sqlalchemy.engine.Engine INSERT INTO campaign (name, due_date, created_at) VALUES (?, ?, ?) RETURNING campaign_id\n2025-08-23 23:37:07,822 INFO sqlalchemy.engine.Engine [generated in 0.00007s (insertmanyvalues) 1/2 (ordered; batch not supported)] ('Summer Launch', '2025-09-01', '2025-08-24 03:37:07.821967')\n2025-08-23 23:37:07,823 INFO sqlalchemy.engine.Engine INSERT INTO campaign (name, due_date, created_at) VALUES (?, ?, ?) RETURNING campaign_id\n2025-08-23 23:37:07,823 INFO sqlalchemy.engine.Engine [insertmanyvalues 2/2 (ordered; batch not supported)] ('Black Friday', '2025-11-28', '2025-08-24 03:37:07.822038')\n2025-08-23 23:37:07,823 INFO sqlalchemy.engine.Engine COMMIT\n INFO Application startup complete.\n```\n\n### Seeding the Database\n\nSince you can wipe the database whenever you want, I like to seed it with a couple of rows so there's always something to read back. That's the `session.add_all` block inside the lifespan.\n\nThe check in front of it, `if not session.exec(select(Campaign)).first():`, is kinda like a create table if not exists, but for an insert. If the table already has data we do nothing, if it's empty we create two rows.\n\nNote this needs the `Campaign` model to exist, which is why the model has to be defined above the lifespan function.\n\n### GET\n\nNow the endpoint itself. `session.exec(select(Campaign)).all()` is what you use to retrieve multiple values, and we wrap the result in a dictionary the same way we did with the mock data.\n\nIf you hit the endpoint from the docs page you'll get the two seeded campaigns back. Their due dates will look identical since I generated both with `datetime.now(timezone.utc)`, but you could set custom values in the seed.\n\n### Types\n\nBefore replacing the rest of the functions, take a look at the docs page. The response structure just says string, so a consumer of your API learns nothing from it.\n\nThat's what `response_model` fixes. We have an expected return type which we created as a custom object containing the response. This matches the expected structure which can be seen in the docs:\n\n```json\n{\n \"campaigns\": [\n {\n \"name\": \"Summer Launch\",\n \"due_date\": \"2025-09-01\",\n \"campaign_id\": 1,\n \"created_at\": \"2025-08-24T03:38:58.592405\"\n },\n {\n \"name\": \"Black Friday\",\n \"due_date\": \"2025-11-28\",\n \"campaign_id\": 2,\n \"created_at\": \"2025-08-24T03:38:58.592468\"\n }\n ]\n}\n```\n\nIf you are using the REST Client:\n\n```\nHTTP/1.1 200 OK\ndate: Mon, 25 Aug 2025 07:50:53 GMT\nserver: uvicorn\ncontent-length: 237\ncontent-type: application/json\nconnection: close\n\n{\n \"data\": [\n {\n \"name\": \"Summer Launch\",\n \"due_date\": \"2025-09-01T00:00:00\",\n \"campaign_id\": 1,\n \"created_at\": \"2025-08-25T07:50:50.346637\"\n },\n {\n \"name\": \"Black Friday\",\n \"due_date\": \"2025-11-28T00:00:00\",\n \"campaign_id\": 2,\n \"created_at\": \"2025-08-25T07:50:50.346703\"\n }\n ]\n}\n```\n\nWithout the nested type we would only return an array or an object.\n\nLet's look at the docs. You'll see our custom type as the return.\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/byzJ89CV_9pZ.png)\n\nDefining these explicit types helps with the API documentation so consumers of this know exactly what to expect. You may also be able to generate client code off of it.\n\nYou may see variations in the typing, another common approach is to return a specific type directly. Here is an example returning a list of campaigns using Python type hints. However I found this approach makes it easier to run in to type issues (forcing me to convert it to a list, or not liking me nest data in a dictionary).\n\n```python\n@app.get(\"/campaigns\")\nasync def read_campaigns(session: SessionDep) -> list[Campaign]:\n data = list(session.exec(select(Campaign)).all())\n return data\n```\n\nSee this doc for more info on this problem - [Response Model - Return Type - FastAPI](https://fastapi.tiangolo.com/tutorial/response-model/#response_model-parameter)\n\nFor example I tried this:\n\n```python\n@app.get(\"/campaigns\")\nasync def read_campaigns(session: SessionDep) -> dict[str, list[Campaign]]:\n data = list(session.exec(select(Campaign)).all())\n return {\"campaigns\": data}\n```\n\nBut the expected response type was way less clear:\n\n```json\n{\n \"additionalProp1\": [\n {\n \"campaign_id\": 0,\n \"name\": \"string\",\n \"due_date\": \"2025-08-24T04:03:50.877Z\",\n \"created_at\": \"2025-08-24T04:03:50.877Z\"\n }\n ],\n \"additionalProp2\": [\n {\n \"campaign_id\": 0,\n \"name\": \"string\",\n \"due_date\": \"2025-08-24T04:03:50.877Z\",\n \"created_at\": \"2025-08-24T04:03:50.877Z\"\n }\n ],\n \"additionalProp3\": [\n {\n \"campaign_id\": 0,\n \"name\": \"string\",\n \"due_date\": \"2025-08-24T04:03:50.877Z\",\n \"created_at\": \"2025-08-24T04:03:50.877Z\"\n }\n ]\n}\n```\n\nDidn't explicitly state there would only be one attribute, or that the attribute would always have a certain name. Wasn't sure if there was a way to improve it but ultimately I went the `response_model` route.\n\n### GET BY ID\n\nFor a single row you use `session.get` instead of `session.exec`. Pass it the table and the ID and you get one record or `None`.\n\n### Generic Response Type\n\nIf every endpoint needs its own response class, you end up writing a lot of near-identical classes. So instead of a `CampaignsResponse`, we make ONE generic `Response` type, and provide the inner type at the point of use. The attribute will just be `data`, but this simplifies our type surface area.\n\nIf you've seen square brackets after a type in this lesson, like `list[Campaign]`, that's a generic. Same idea here, except we're making our own, and the thing we substitute in is a TYPE, not a value.\n\n```python\nfrom typing import Generic, TypeVar\n\nT = TypeVar(\"T\")\n\nclass Response(BaseModel, Generic[T]):\n data: T\n\n@app.get(\"/campaigns\", response_model=Response[list[Campaign]])\nasync def read_campaigns(session: SessionDep):\n data = session.exec(select(Campaign)).all()\n return {\"data\": data}\n\n@app.get(\"/campaigns/{id}\", response_model=Response[Campaign])\nasync def read_campaign(id: int, session: SessionDep):\n data = session.get(Campaign, id)\n if not data:\n raise HTTPException(status_code=404)\n return {\"data\": data}\n```\n\nNote that both routes now return `{\"data\": ...}`. That's the trade-off, the key is always `data`, but the consumer knows it's consistently the same attribute, and the structure underneath differs (a list of campaigns in one, a single campaign in the other).\n\n> [!tip]\n> `Response` is also the name of the class we imported from FastAPI for the mocked DELETE. Once the mock endpoints are gone we don't need that import, so I just removed it. If you still need it, alias the import or rename your custom type.\n\n> [!tip]\n> What are the key differences between BaseModel and SQLModel without table=True? Would be good to do additional research here.\n\nYou will see two return type possibilities for `read_campaign`.\n\n![](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson-migration/2026/07/asOPwFRPoET2.png)\n\nTest this out by visiting a path that does not have a proper ID:\n[http://127.0.0.1:8000/api/v1/campaigns/hello](http://127.0.0.1:8000/api/v1/campaigns/hello)\n\nTest it with an ID that doesn't exist as well and make sure you get a 404.\n\n### POST - Creating data\n\n```python\n@app.post(\"/campaigns\", status_code=201, response_model=Response[Campaign])\nasync def create_campaign(campaign: CampaignCreate, session: SessionDep):\n db_campaign = Campaign.model_validate(campaign)\n session.add(db_campaign)\n session.commit()\n session.refresh(db_campaign)\n return {\"data\": db_campaign}\n```\n\nThis will process the body automatically when we have the `campaign` parameter, so we don't have to manually grab anything from the body. It's all taken care of for you by the time the function is hit. This will show in the API docs.\n\nThe `session.refresh` matters because the database does additional stuff on insert. It assigns the ID, it fills the `created_at`, it might do transformations. Refreshing makes sure `db_campaign` has all of that before we hand it back to the user.\n\n> [!tip]\n> I intentionally did not embed the request type in an attribute like data. Usually the request body is flat, but anything is possible.\n\n### Custom create type\n\nMy first attempt at the POST typed the body as `Campaign` directly, and it 500'd:\n\n```\nsqlalchemy.exc.StatementError: (builtins.TypeError) SQLite Date type only accepts Python date objects as input.\n[SQL: INSERT INTO campaign (name, due_date, created_at) VALUES (?, ?, ?)]\n[parameters: [{'created_at': datetime.datetime(2025, 8, 25, 2, 7, 23, 351328, tzinfo=datetime.timezone.utc), 'name': 'new campaign', 'due_date': '2025-12-25'}]]\n```\n\nThe problem is that the request body type has an ID and a `created_at` that should be handled server side, and the client shouldn't be sending them at all. Our POST request should look something like this:\n\n```json\n{\n \"name\": \"new campaign\",\n \"due_date\": \"2025-08-24T04:03:50.877Z\"\n}\n```\n\nReally we need to create specific types for every variation we may expect.\n\nLet's start with a `CampaignCreate`. Naming convention starts with the noun otherwise it sounds like a function. That way every variation of this type starts with `Campaign` and they're easy to find together.\n\nWe will only use `table=True` for the type that exactly aligns with the database structure. `CampaignCreate` has two attributes, the table has four, so it does not get `table=True`.\n\n```python\nclass Campaign(SQLModel, table=True):\n campaign_id: int | None = Field(default=None, primary_key=True)\n name: str = Field(index=True)\n due_date: datetime | None = Field(default=None, index=True)\n created_at: datetime = Field(default_factory=lambda: datetime.now(timezone.utc), index=True)\n\nclass CampaignCreate(SQLModel):\n name: str\n due_date: datetime | None = None\n```\n\nWe invoke `model_validate` to check the body of the request against the database structure, we add it to the db and commit the change. We then refresh which will ensure the latest data is on `db_campaign`, which we then return to the user.\n\nThis is the only variation we NEED, but you'll definitely want to familiarize yourself with this idea for when you end up working with passwords and other sensitive data, as you can use this approach to manipulate what fields are sent back to the client so sensitive info doesn't get leaked. For now we have nothing sensitive.\n\n### PUT - Updating Data\n\nWe can use that same `CampaignCreate` model for updating, since name and due date are the only two things a client would change. You could make a `CampaignUpdate` instead but I think this is fine.\n\nAlso note for PUT the timestamps should be system owned, so for those specific attributes it should act more like a PATCH (not removing the attribute if not provided by the client).\n\nDeleting data is EZ too.\n\n```python\n@app.put(\"/campaigns/{id}\", response_model=Response[Campaign])\nasync def update_campaign(id: int, campaign: CampaignCreate, session: SessionDep):\n data = session.get(Campaign, id)\n if not data:\n raise HTTPException(status_code=404)\n data.name = campaign.name\n data.due_date = campaign.due_date\n session.add(data)\n session.commit()\n session.refresh(data)\n return {\"data\": data}\n\n@app.delete(\"/campaigns/{id}\", status_code=204)\nasync def delete_campaign(id: int, session: SessionDep):\n data = session.get(Campaign, id)\n if not data:\n raise HTTPException(status_code=404)\n session.delete(data)\n session.commit()\n```\n\nOne gotcha on the PUT. I named the path parameter `campaign_id` in the signature and then used `id` in the body of the function, which gave me a 500. That works because `id` is a Python builtin, so it resolves to something, just not what I wanted. I've been shadowing `id` this whole lesson, which is not the end of the world if you're not using the builtin, but prefixing with `campaign_id` is the healthier habit.\n\nCongrats, at this point you now have full CRUD capability on a pretty basic example.\nIt's a lot to learn and we covered a lot. There's more I want to cover, so please continue in this playlist.\n\nAt this point you'll want to commit the project.\n\n```bash\ngit add .\ngit commit -m \"basic DB CRUD\"\ngit push origin main\n```\n\nThat push will fail if you never made the remote repo, which is exactly what happened to me, so create it on GitHub first. Mine is at [https://github.com/CalebCurry/fastapi-example](https://github.com/CalebCurry/fastapi-example).\n\nEverything is still in one single file, and obviously as you grow you'll want to break things out. You might group everything campaign related together, or go more of an MVC route with the models, views, and controllers separated. That's a later lesson.\n\nWhat's next:\n\n- relationships, this one will be huge\n- pagination and URL parameters\n- organizing our code structure\n- middleware\n- User authentication and more!\n\n---\n\nIf you've enjoyed any of this material I encourage you to check out my courses. These cover topics comprehensively and are a great way to level up your engineering skills and career. You'll also gain access to the CodeBreakthrough community for networking and accountability.\nTo get started, check out [Software Engineering Fundamentals](https://www.codebreakthrough.com/software-engineering-fundamentals).\nYou can use coupon code **NOTES** to get 15% off.",[],[],"d5db0365-2996-443d-8043-3a5521559954",4326,1280,720,"fastapi-intro-full-crud-rest-api-tutorial-1-hour-backend-engineering","API Pagination - Offset and Cursor Pagination Explained - Backend Engineering",24,"api-pagination-offset-and-cursor-pagination-explained-backend-engineering","Offset and Limit Pagination Tutorial (API Design) - Backend Engineering",23,"offset-and-limit-pagination-tutorial-api-design-backend-engineering",22,"api-cursor-pagination-infinite-scroll-backend-engineering","teaser",{"_566":568,"_569":570},"**🔗 PENDING EMBED — review:** Notion bookmark — \n\nThis is a decent starting point to understand some of the concepts:\nHow to implement cursors for pagination in an api\n\nFirst, let's start with a simple structure that uses an ID.\n\nTo make sure we are on the same page, the ID passed as the cursor can be thought of as `last_seen` , so you want to start AFTER that point in the DB.","outline",[571],"Encoding + Decoding","Need to Learn Data Structures and Algorithms? Watch this",21,"need-to-learn-data-structures-and-algorithms-watch-this","AI Is Out of Control (here's why)",20,"ai-is-out-of-control-here-s-why","Data Structures and Algorithms to Know as a Software Engineer (Know these to be a better dev)",19,"data-structures-and-algorithms-to-know-as-a-software-engineer-know-these-to-be-a","Intro to Authentication - User and API Auth",18,"intro-to-authentication-user-and-api-auth","How to Learn Python - 8 Week Python Mastery",17,"how-to-learn-python-8-week-python-mastery","What You Need to Know to Master Python (Fundamentals, Libraries, AI, Machine Learning, Backend)",16,"what-you-need-to-know-to-master-python-fundamentals-libraries-ai-machine-learnin","Advanced Software Engineering Course Announcement",15,"advanced-software-engineering-course-announcement","These 90 Minutes Will Change the Way You Use AI",14,"## Timestamps\n\n- `00:00:00` - Introduction\n- `00:02:37` - Where Would You Use an LLM?\n- `00:04:11` - Instruction Files\n- `00:06:38` - Multi Tenant Service\n- `00:09:10` - Convert Thinking into Deterministic Rules\n- `00:12:40` - Using Checks to Enforce Quality\n- `00:15:30` - Linting\n- `00:25:29` - Components\n- `00:30:43` - Self Learning AI\n- `00:33:16` - Skills and Subagents\n- `00:35:38` - Main Orchestrator\n- `00:42:31` - APIs and MCP\n- `00:45:30` - AI Features vs MCP\n- `00:52:58` - Permissions\n- `00:59:37` - Isolated LLMs\n- `01:03:38` - Identify Workflow Problems\n- `01:05:11` - Prototyping with AI\n- `01:10:13` - Hooks\n- `01:15:27` - Debugging and Listeners\n- `01:20:17` - Monitors\n- `01:21:26` - Approach to Building with LLMs\n- `01:28:11` - Next Steps\n\nThis video is a walkthrough of how I actually use AI day to day running my course platform. Not prompting tips, the system around the AI: instruction files, checks, skills, subagents, hooks, and permissions. The notes below are grouped to match the timestamps at the top, so you can jump around.\n\n### Where Would You Use an LLM?\n\nThe magic of an LLM is that it can make decisions, which is something that's hard to articulate in a script without covering every possible scenario. The tradeoff is the output is unknown. Ask it the same question twice and you might get two different answers.\n\nThis is called **non-deterministic**: same input, potentially different output. That's actually one of the strengths of an LLM, if you use it in the right place.\n\nThe mistake a lot of people make is using something non-deterministic to do work that's deterministic (same input always gives the same output). If the task is deterministic, you want a script, it'll give you the same result every single time. This framing carries through the whole lesson.\n\n### Instruction Files\n\nEvery AI coding tool supports some kind of instruction file (Claude Code uses [CLAUDE.md](https://docs.anthropic.com/en/docs/claude-code/memory)). This is just a markdown file in your project that gets loaded in to every conversation.\n\nThe catch is that the AI interprets the file. It's great for instruction, but it's not ideal for enforcing things. That was the biggest breakthrough I had: I was instructing the LLM through a bunch of rules written in md files, and they were often not being followed, or I was getting inconsistent results.\n\nStill treat it as a living document. Any time the AI does something you didn't want, ask whether a rule would have prevented it, then add the rule:\n\n```markdown\n## Database\n- Never connect to the database directly, use the helper commands\n- Never push schema changes, always require a migration file\n\n## UI\n- Check if a component exists before creating a new one\n- No inline styles except for dynamic values\n```\n\nMine has grown to cover naming conventions, styling, imports, and a checklist the AI runs through before writing code. Just don't expect any of it to be followed 100% of the time. Fixing that expectation is what the next few sections are about.\n\n### Multi Tenant Service\n\nA concrete example of the problem. My project is a multi-tenant service: one database serving multiple instances, and each instance serves its own end users. Data should never cross between tenants, ever.\n\nMy first attempt was an instruction, basically \"respect tenant scoping\". That's risky, because the moment it gets skipped you're showing somebody data that belongs to someone else.\n\nSo instead of relying on the rule, we extended the database layer to always infuse the tenant. A query like `SELECT * FROM products` never reaches the database without the tenant attached, the adapter adds it automatically. Now it can't be forgotten, because there's nothing to remember. This is exactly the kind of thing that gets missed when someone is vibe coding with no insight into how things actually work.\n\n### Convert Thinking into Deterministic Rules\n\nAn LLM is non-deterministic. A script is not. Whenever the AI keeps making the same judgment call, I try to turn that judgment in to a check that runs the same way every time. I call these gates: the result has to pass them to count as done. Lint rules are the easiest example:\n\n```js\n// ESLint: ban reading env vars directly, force the validated module\n\"no-restricted-syntax\": [\n \"error\",\n {\n \"selector\": \"MemberExpression[object.property.name='env']\",\n \"message\": \"Read env vars through the validated env module.\"\n }\n]\n```\n\nOnce a rule is a lint error, you never have to remind the AI again. It hits the error, reads the message, and fixes itself. The message IS the documentation.\n\nYou don't have to write these yourself either. Ask your AI to look at your code and figure out what could be converted into checks that always run, you'd be surprised what it comes up with.\n\nThere's a second benefit: tokens. Running a script is cheap, asking an AI to scan your project for issues is expensive. Fine to do every now and again, but if you want it on every code change, make it a script.\n\nFor the stuff that's too fuzzy for a script, pair the gates with a **verifier**, a subagent with a rules file of opinionated checks: code smells, anti-patterns, standards you've defined. Removing everything deterministic from the verifier keeps it focused. A classic entry in that rules file is N+1 queries, retrieving a set of elements and then hitting the database once per element in a loop. Hard to lint for, easy for a verifier to spot.\n\n### Using Checks to Enforce Quality\n\nThe goal here is a little counterintuitive: we're making it more difficult for code to reach production, not easier. Everybody wants AI so code ships faster, but the checks are what let you ship fast without shipping garbage. The layers stack:\n\n- Your stack choices (I use TypeScript over JavaScript, with no implicit or explicit `any`)\n- CLAUDE.md instructions\n- Linting and custom check scripts\n- A verifier subagent for the opinionated stuff\n- Hooks, in the AI or in git\n- Automated tests\n- AI code review on pull requests, tied into CI/CD\n\nDo every one of these and your software will be dramatically better than someone who opens a terminal and says \"yo build me something cool, don't make any mistakes\".\n\n### Linting\n\nA few lint setups that pay off for pretty much any project.\n\nFirst, ratcheting. Say you have a thousand TypeScript errors. Set it up so the count can only ever go down: new errors block progress like a compilation error, existing ones are grandfathered in. It's a way to acknowledge the bad past and set new standards going forward. Ask your LLM to set this up, it can figure it out.\n\nThe one that made the biggest difference for me is a line count limit on files. Mine is set at 1000, adjust for how you split your files. I was working on a builder that was a few thousand lines, and any time the AI changed anything it had some side effect breaking something else. Every change introduced a regression, or it would bring back earlier features, or just make stuff up. That problem is way less common with smaller files. I think AI performs best in the 500 to 1000 line range. I still have around 20 files breaking my own rule, which is why I ratchet it instead of failing outright.\n\nRelated: extract logic into pure, testable functions. The component keeps the visual layer and the styling, the logic lives in functions the component calls. Those functions get basic unit tests. If you don't want to build big end-to-end suites with Playwright, this is the low-hanging fruit.\n\nThis matters most when you generalize components. Say a page uses some component and later you want the same thing somewhere else. Copying it means variations to manage, and any core change has to happen in multiple files that drift out of sync. Generalizing it means abstraction and conditionals, and what worked 100% of the time now works 95%. I hit this with a checkout modal, a sensitive part of the app I did not want to touch once it finally worked, so I duplicated it and paid for that for a long time. Tests on the component are what make extraction safe later.\n\nSome other custom checks I run: synchronization checks so my API layer and its documentation can't drift (the AI wrote these itself when I asked if drift was preventable), every endpoint required to have authentication and validation, no server imports in client code, and an environment variable check so a deploy can't go out missing a var. That last one has actually saved me, I made some small change, went to deploy, and the check said no, your environment variables don't match. Plus the standard stuff: strict TypeScript, Prettier formatting enforced. Pretty much anything pre-AI you'd enforce at compile time or in CI, do all of it.\n\n### Components\n\nFor instructions the AI needs on demand, one massive CLAUDE.md dilutes everything with junk. What works better is using CLAUDE.md as a table of contents pointing at scoped files.\n\nI keep those files in a `vault/` folder at the root of the repo and work with them through [Obsidian](https://obsidian.md/). I started on Notion, but Obsidian gave me the same experience with raw md files that live in the repo, so the AI can read them directly.\n\nThe first file I'd create is `components.md`, a catalog of every reusable component: the selects, the paginated table, whatever you have. Then a rule: check `components.md` before creating new components. Without this the AI will happily build you a fourth variation of the same button, I had that exact situation on one page.\n\nAt one point my CLAUDE.md said \"do not use alerts\" multiple times and it would just keep using alerts, completely ignoring me. The fix was moving it into a lint rule. No alerts, problem solved. Same with console logs. If it's not very important, CLAUDE.md is fine. If it's important, tie it into linting somehow. You could even lint against raw HTML elements so everything has to go through your component directory. I haven't personally done that one, but it would work.\n\n### Self Learning AI\n\nThe next level of the vault: structure it by the domains of your app (services, security, auth, the big features) and tell the AI in CLAUDE.md to update these documents as it goes. Feature specs, architecture decisions, migrations in progress, anything that's a big project gets documented as it happens.\n\nHonestly these notes are less for me and more for future conversations with the LLM. It can refer back to decisions instead of relying on memory.\n\nHere's why I think this matters. With AI, single developers are building full software suites, and the limitation is no longer the ability to code. Zoomed out it's the ability to build something people want. Zoomed in, it's remembering everything you decided: the architecture, the design documents, the choices. That's what the vault holds.\n\nAnd when the AI makes a mistake and you correct it, that correction should land somewhere permanent: the instruction file, a lint rule, or the vault. The workflow slowly gets better because every failure becomes a rule.\n\n### Skills and Subagents\n\nTwo tools in Claude Code that sound similar but aren't. The difference is where the context goes: a **skill** brings all of its information into your main chat's context, a **subagent** manages its own context and only sees what you hand it.\n\nSo the split is: anything you repeat and want available mid-conversation goes in a skill (design guidelines, content planning, making a PR). Anything you can isolate goes in a subagent (research that summarizes something from the internet, a test writer that works on the side while you build). The value of the subagent is it does all its work in its own little bubble and just hands back the result, so your main context stays clean.\n\n### Main Orchestrator\n\nFor more complex work I take this further: the main chat becomes an orchestrator that launches **bundles** in the background. Each bundle has its own sub-orchestrator in charge of building one feature end to end, and it delegates: a planner writes the spec, an implementer codes it, a tester writes tests and makes sure existing ones still pass, and the verifier/challenger checks that what we built is what we wanted and isn't overcomplicated. You can think of it as building a small team for a goal.\n\nI wrote all of this up as a skill, I called it launch. I describe the feature, it launches a bundle in the background, and the main loop stays free so I can keep chatting or launch more bundles in parallel. I don't have to wait an hour or two for one to finish.\n\nA few things that make it work:\n\n- The spec is the authority. Most questions happen up front while designing it, and the other agents just implement, test, and verify against it. Front-loading the design questions is what lets it run for hours without me.\n- Agents triage their questions and only bubble up the ones above a threshold that actually affect design or implementation choices.\n- You can assign different models to different roles: a heavier thinking model for the planner and manager, cheaper models for implementation that's just following the spec.\n\nFair warning: done poorly this just adds bureaucracy to your AI agents, they go back and forth changing each other's work and burn credits without converging. I'd only recommend this structure once everything earlier in this lesson is already working for you, and probably only on a plan where you have credits to spare. It's overkill for small stuff.\n\n### APIs and MCP\n\nBuild a real API first, then expose it through MCP. **MCP** is a standard for giving an LLM access to tools, you can think of it as an API designed for agents. Once my platform had a public API, wrapping it in an MCP server meant you can connect your AI and say \"draft up a high ticket product, create some landing pages, draft some emails\" and it all happens on your live account. The API is the product, MCP is the adapter.\n\nWhen a service you use has no MCP server, check for an API. An LLM can do pretty much the same stuff with an API key and the documentation, especially if the API has an [OpenAPI](https://swagger.io/specification/) spec, mine does. Worst case you can grab your cookies from dev tools and let the AI act through the browser session, but that's the high-risk option. Check for MCP first, then API, then get creative.\n\n### AI Features vs MCP\n\nPut your developer hat on for this one. You can build AI features into your app, buttons that summarize documents or generate things. Or you can expose those same capabilities through MCP and let the user's own LLM do the work. There's a lot of overlap.\n\nI had started building page generation and editing inside my app, and I paused it and moved that capability into the MCP instead. Two reasons. One entry point for doing anything in the app made more sense than sprinkling AI features everywhere. And with in-app features I pay the tokens and have to manage limits and credits, with MCP the user's LLM pays. I just didn't want to start with all that complexity.\n\nIt doesn't always go that way, though. My users' end users are a different story: someone watching a course video who wants to ask a question about the lesson is not going to connect an LLM first, they just want to click a button. For that audience the AI belongs inside the app. Think about who the user is and what they'll actually tolerate setting up.\n\nOne layer deeper: an MCP server is a collection of tools, and I mapped mine one-to-one with my API endpoints, which made the MCP layer very quick to build. Each tool carries a description, which is context you feed the LLM so it knows how to use the tool correctly without guessing. That's the main edge MCP has over handing it a raw API key. I might build more purpose-driven tools eventually, but one-to-one got it shipped.\n\n### Permissions\n\nClaude Code has a flag to skip all permission prompts. I avoided it for the longest time, I assumed it was just reckless. What I figured out is it's not the command's problem, it's the user's problem if they use it without the right setup. Before you go anywhere near it, do the boring version first: add your common commands to the allow and deny lists. Those persist between sessions, unlike the yes buttons you click mid-session, which only last for that session.\n\nThe deny list is where it gets interesting. I denied direct `psql` and required going through `docker exec` instead, so the AI can reach the dockerized project database but can't guess its way into some other database on my system (I had a locally installed Postgres it kept trying to use). I deny `db push` style commands that skip migrations, because applying directly to the database creates drift between the schema and the migration files. Anything destructive in version control, like `git reset`, is worth denying too.\n\nOne mental adjustment: think of these permissions as guidance for the LLM, not security. They genuinely help it pick the right database and avoid destructive habits, and after you deny something once it stops for every future session. But there are ways to mask the true intent of a command, so if you imagine a genuinely bad AI or a prompt injection attack, deny rules alone won't save you. That's what isolation is for.\n\n### Isolated LLMs\n\nIf your machine has the local connection string and the production connection string sitting next to each other, and your plan is telling the LLM to choose carefully, you're set up for a bad day. We don't want to instruct the AI to be careful, we want to make the bad thing impossible by removing access altogether.\n\nSo I run Claude inside a Docker container. The container mounts the repo and nothing else. My GitHub credentials, my cloud provider CLIs with keys to real infrastructure, anything sensitive lives outside the repo, so the container simply cannot touch it. It can make commits locally, but it can't push or pull from my private repo, because the credentials aren't there.\n\nThe split that falls out of this: long-running autonomous work happens inside the container with permissions relaxed. Anything that touches GitHub or production runs from Claude outside the container with permissions ON, so I see every command that could hurt something. I run multiple containers at once, all working in the same repo, sharing a database container for the app but each with its own test database so they can run tests independently.\n\n### Identify Workflow Problems\n\nA small instruction with outsized returns: tell the AI, in CLAUDE.md, to identify workflow problems and improve them. Specifically the skills and subagents you've defined and your document structures. It's not guaranteed to run every moment, but having it in context means the setup improves as you use it.\n\nAnd whenever I notice the AI doing something funky, I just tell it to take the issue we hit and put it in the vault so we don't run in to it again. The goal is improvement happening recurrently instead of me manually tuning things forever.\n\n### Prototyping with AI\n\nI'm by no means a design expert, and this is what got me furthest: anchor every request to an example. I spent some time up front having the AI build a reference library in my vault, example themes, landing pages, widgets, analytics views, about a hundred pages as one big HTML file I can click through. None of it ships. When I need to design something, I find a page I like and say \"design it based off this example\". Anchored instructions get much better results than descriptions.\n\nThe other half is prototyping flows before wiring anything up. Payment flows are painful to test for real: create an account, buy the product, then revoke it to test again. Instead I had the AI build the whole thing as front end only, with buttons to flip between states: not logged in, logged in and owns the product, logged in and hasn't bought. I click through every path, fix what looks wrong, and then that prototype becomes the spec for the real implementation. By the time the backend exists there's barely anything left to discover. Raw HTML and CSS is usually enough, sometimes React if I want it more engaging.\n\n### Hooks\n\nHooks are code that runs at fixed points in the agent's loop, before a tool call, after a file edit, when a session ends. Very similar to middleware in web requests. Unlike instructions, a hook can't be ignored or forgotten, it executes every time:\n\n```json\n{\n \"hooks\": {\n \"PostToolUse\": [\n {\n \"matcher\": \"Edit|Write\",\n \"hooks\": [{ \"type\": \"command\", \"command\": \"npm run lint:changed\" }]\n }\n ]\n }\n}\n```\n\nThere are a bunch of events (SessionStart, UserPromptSubmit, PreToolUse, SubagentStart, Stop, and more), the full list with input schemas is in the [hooks documentation](https://docs.anthropic.com/en/docs/claude-code/hooks). The two I lean on: PreToolUse with a matcher to intercept and block dangerous executions before they run, and Stop, which fires after the AI finishes a full response.\n\nA hook is a script, not a prompt. The script runs, and its return gets fed back to the LLM, which can send it back to fix its work. Mine are just JavaScript files: the PreToolUse one blocks bad commands, the Stop one runs the lint ratchet so a response can't end with new violations. Worth asking for each check: does this need to run after every single tool use, or can it wait until the end of the response? I moved most of mine to Stop.\n\nOne more use case: people run with full permissions but use hooks to block specific things, since bypassing permissions ignores allow/deny rules but hooks still fire.\n\n### Debugging and Listeners\n\nTests first, as always, and pure functions make the tests worth something: isolate logic with no side effects, and after a change, same input giving the same output means high confidence nothing broke. I once added a new coupon type tied to accounts and had to re-verify every place a coupon gets used on the site. Smoke testing a large app by hand is exhausting, coverage is what makes changes like that cheap.\n\nTwo things AI is unusually good at here. First, tracing: when a request returns something you don't expect, don't hand the AI the error, ask it to trace the request end to end from request to response. It's much better than us at jumping between functions, and it'll find the transformation you weren't expecting. It can run its own servers and read its own logs along the way.\n\nSecond, reading logs. The core of what these models do is find associations in inputs too high-dimensional for a human, and log analysis is exactly that shape. Get production logs in front of the LLM and it can sift for patterns, connect requests, spot the weird thing. I wrote a skill instructing how I want logs read and now I can pass it a request and ask arbitrary questions, way easier than digging through the logs myself.\n\n### Monitors\n\nMonitors take the log idea real time: an event happens on production, the log gets forwarded to your LLM, and it reasons about whether it's a problem. This is a layer above normal alerting and observability, because it's not triggering on a threshold or a specific error, it can think through whether something strange is happening across the logs.\n\nThis is how you get autonomous AI that isn't just building your software but actually running your operations. I feel like I've got the building side locked in, so this is where my time is going next.\n\n### Approach to Building with LLMs\n\nYou'll progress through stages: AI as an assistant, then it writes code and you go back and forth, then it writes big sections you review, then multiple agents running at once. These days I'll literally have four Claude windows on my desktop doing different things, or several bundles running inside one instance. Since a feature takes an hour or a few to build and verify on its own, running four at once is not as crazy as it sounds.\n\nSome habits that make the parallel thing work:\n\n- Keep conversations focused and clear the context when you switch topics.\n- Commit freely. I used pre-commit hooks for a while and they just made me delay commits because every commit meant fixing everything first. Now I don't care what's committed, I only care what's pushed to production, that's a separate step in my mind.\n- Worktrees give agents isolated copies of the code, and they're the common answer for multiple LLMs on one codebase. I haven't needed them, I just scope the parallel work to different areas of the app (Slack notifications here, MCP layer there, design work in the third) and told the AI in the instructions that other agents may be editing files, so respect changes it didn't make.\n\nOn reviewing everything: I don't. The more important the code, the more attention it gets. My page builder renders from a JSON structure where old versions have to keep rendering, so changes there are low stakes and I barely read them, same with design work, I check that it looks right and the structure is sane. Payments code I read closely. Right now I work as an operator managing these different agents and reviewing what matters before anything deploys.\n\nI still have days where I turn the AI off and code by hand, and it's usually the right call for anything I don't understand yet. I needed a feature that summarized notes into a chat system with vectorized data in the database, all new territory for me, and having the AI just implement it produced code I didn't understand. I took a couple of days to build the core myself, and then having the AI extend it was easy, because I could actually review the changes.\n\nLast one: I have a separate Claude review PRs going into main, and it finds real issues precisely because it isn't the instance that wrote the code. Cleared context, reading with the intent of finding problems. Same spirit as the verifier, just tied into GitHub.\n\nThe bigger picture: before AI, a software org wasn't all people writing code. The higher you went, the more you thought about bigger problems, reviewed code, and drove features instead of implementing. That's the mode AI unlocks for a single developer, and if you don't develop that skill you're going to struggle.",[],[],"3d63f68c-946d-477a-8851-cf2388ed3fb5",5322,"these-90-minutes-will-change-the-way-you-use-ai","Claude Code Introduction - Full Crash Course (1 HOUR)",13,"## Timestamps\n\n- `00:00` - Intro\n- `00:58` - Install Claude Code\n- `01:59` - Getting Started\n- `02:55` - Create Your CLAUDE.md\n- `04:49` - Make Your First Commit\n- `06:34` - Create a Vault\n- `08:06` - Obsidian\n- `08:55` - Models & Credits\n- `11:11` - Usage\n- `13:55` - Skills\n- `20:18` - Permissions\n- `25:28` - Deny Rules\n- `29:40` - Commit Hooks\n- `30:39` - Let's Build\n- `31:37` - Basic v1 Spec\n- `32:03` - Creating the Spec\n- `42:10` - Auto Mode\n- `45:40` - Headless Browsers\n- `48:47` - Hooks\n- `52:54` - MCP\n\nClaude Code is an agent that runs in your terminal. It reads your files, edits them, and runs commands, which is a different thing than autocomplete in your editor.\n\nI've been running my whole platform with it for the last six months, and it's saved me hundreds, probably thousands of hours. This crash course is the follow-along version: we start from nothing, install it, and try a small example of every piece, so you can put it to work whether or not you write code for a living.\n\nThese are the free notes for the video, with the commands and code so you can follow along without pausing every ten seconds. When you want the full system, how I actually run software and a business on this every day, that's my [Agentic AI course](https://codebreakthrough.io/agentic-ai).\n\n## Installing\n\nThere's a download button on the Claude Code page that gives you a desktop app, and it's fine, but I run everything from the terminal. That's where Claude Code is at its best.\n\nBefore you install, make a folder and work from there instead of your home directory. Permissions get scoped to wherever you launch Claude, and you don't want your whole home folder as its playground.\n\n```bash\nmkdir claude-code\ncd claude-code\n```\n\nGrab the install command off the [setup docs](https://code.claude.com/docs/en/setup). I'm on macOS, and the command I copied was the native installer:\n\n```bash\ncurl -fsSL https://claude.ai/install.sh | bash\n```\n\nThere's an npm install too if you already live in Node, and on Windows you run the installer from PowerShell or the command prompt:\n\n```bash\nnpm install -g @anthropic-ai/claude-code\n```\n\nCheck it landed:\n\n```bash\nclaude --version\n```\n\n## First Run\n\nStart it by typing `claude`:\n\n```bash\nclaude\n```\n\nFirst time in, you authenticate. If you're ever signed out later, `/login` reconnects you to your Anthropic account, where you pick your monthly subscription or API credits (there are a couple of third-party options too, but it's usually just the subscription).\n\nNow type `/` and a menu of everything pops up, arrow keys and enter to run one. Poke around in there, that's how you find things like hooks later.\n\nTwo survival basics. To quit, run `/exit`, or hit `Ctrl+C` twice. And whenever you close Claude it forgets every permission you approved for that session, so instead of closing and relaunching to start over, use `/clear`. It wipes the conversation and leaves you where you are. Do it any time you switch topics.\n\n## CLAUDE.md\n\n`CLAUDE.md` is a markdown file Claude reads at the start of every session: what the project is, conventions, rules you're tired of repeating. Don't write it by hand. Run:\n\n```\n/init\n```\n\nEven on our empty folder it generates one, a basic template telling future Claude to fill it in as the project grows. On a real codebase it scans the code and writes something with actual structure in it. It'll ask permission first, say yes (and yes-don't-ask-again this session, which is the same as `shift+tab`).\n\nOpen it and read it:\n\n```bash\nless CLAUDE.md\n```\n\nOne thing to get straight early: the `CLAUDE.md` is guidance, not a guarantee. Claude follows it most of the time, not all of the time, and the bigger the file and the project get, the more it slips. So anytime you can actually prevent a mistake instead of asking nicely, do that. Don't write \"don't drop the database\" in here and call it safe, set a rule that makes it impossible. We'll get to those.\n\n## Directing Claude\n\nLet's get the basic project files in. I'll ask for a repo, a readme, a gitignore, and a first commit:\n\n```\ninitialize a repo with a readme and a gitignore and make the first commit.\nkeep the readme empty until we start a real project.\n```\n\nIt stages everything and commits. Read the message it wrote: mine came out as \"initial commit\" with a \"Generated with Claude Code, co-authored by Claude\" footer.\n\nSay I don't want that footer. The move is not to go edit anything myself, it's to tell Claude to change how it works:\n\n```\nadd a rule to CLAUDE.md: commit messages should be lean, no attribution or co-authored-by lines.\n```\n\nCommit again and the next message comes out clean. That loop, notice something you don't like and write the rule down, is what the file is for. Anytime you want to change Claude's behavior, tell Claude, don't reach in yourself unless you really want to.\n\n## A vault\n\nThe `CLAUDE.md` should stay thin. It's a pointer, not a dumping ground. So for everything beyond it I have Claude make a vault, which is just a folder of markdown files.\n\n```\ncreate a vault folder for project info beyond CLAUDE.md.\nkeep it simple for now: one architecture.md, a folder for specs and features, and a file for quality checks.\nCLAUDE.md should just point here.\n```\n\nFor a bigger project you'd build this out per area of the app, but that's the shape. To actually read and edit these I use [Obsidian](https://obsidian.md), which is kind of like Notion mixed with a markdown editor, a little easier to see everything than raw files in your editor. Install it, open a folder as a vault, point it at your project's vault folder, and you can flip any file between edit and read mode.\n\n## Status and diagnostics\n\nBefore going further, `/status` shows your diagnostics: version, and any problems with the install. `/doctor` runs a similar check.\n\nMine flagged multiple installations, an older version shadowing the one I just installed. Instead of untangling that myself, I had Claude do it:\n\n```\nhelp me diagnose this and switch to the latest version I installed via curl. delete the old one.\n```\n\nIt worked out that the old copy came in through npm, uninstalled it, and handed me one command it couldn't run itself. `claude --version` after confirmed the latest. Most of you won't hit this on a first install, the point is that Claude can debug its own environment, not just write your code.\n\n## Models\n\nRun `/model`:\n\n```\n/model\n```\n\nThe exact model names change fast (Fable 5 is the hot one as I record this, and it'll probably be old news in a couple of days), so don't anchor on versions, anchor on the use case. The menu describes them that way: most capable for your hardest and longest-running tasks, best for everyday complex work, efficient for routine stuff, fastest for quick answers. A tiny change like \"make the background darker\"? The fast one is fine. Speccing out real software? Reach for the capable one.\n\nThe tradeoff is money, the smarter the model the faster it burns your usage, and on a cheap plan the top model empties your credits quick. If you're not sure, leave it on default and it picks per task.\n\nThere's also an effort level down at the bottom you can nudge left and right, medium is a fine default. And `/usage` shows how much you've spent this week and this session, worth glancing at so you're not caught off guard.\n\n## Skills\n\nA **skill** is a reusable prompt you invoke with a slash command. You write a workflow down once and type `/whatever-you-named-it` instead of retyping it. People sell these like they're magic, but they're just words pulled in to context, and Claude can write them for you.\n\nLet's make one that commits. Notice I have to say \"create a skill\", or Claude just does the task instead of saving it:\n\n```\ncreate a skill called /commit. before committing, stage all changes and check for large files\nor anything that shouldn't be tracked. if you find something, update the .gitignore and tell me.\n```\n\nThat last bit is a self-improvement trigger, so the skill tightens up the project a little every time it runs. Claude writes a `SKILL.md` that looks about like this:\n\n```markdown\n---\nname: commit\ndescription: Stage all changes and commit, checking for anything that shouldn't be tracked\n---\n\n1. Check for large files or anything that shouldn't be committed.\n2. If you find something, add it to .gitignore and notify me.\n3. Stage all changes and commit.\n```\n\nWhen it saves, it asks where to put it. The default is `~/.claude/skills/`, your user level, available in every project. I'd rather keep this one attached to the repo, so I tab over and put it in `.claude/skills/` instead, checked in and shared with anyone who clones it. Use the user level for skills you want everywhere.\n\nA new skill might not show up until you restart Claude the first time. Then `/commit` runs it. Look at where it lives:\n\n```bash\nls -la .claude\n```\n\nThere's a `skills/commit/SKILL.md`. You can drop scripts in that same folder and the skill can call them, which is how these get more reliable as you invest in them. Mine drift over time. On one project I made the commit skill do so many checks it got bloated and I stopped reaching for it, so I made a lean `commit-fast` that just stages and commits and nothing else. Adjust yours to whatever you actually use.\n\n## Permissions and settings.json\n\nThose allow/allow/allow prompts get old fast. Let's make some permanent. I just ask:\n\n```\nsummarize the permissions this skill needs and add them to my allow rules so it stops asking.\n```\n\nClaude can edit your config for you. When it did mine, it also called out two rules already on my allow list that were risky, `git checkout` and `git reset`, and offered to remove them. I took it. `git reset` wiping out work I've been on for an hour is exactly what I don't want it reaching for on its own.\n\nThe rules live in a settings file. Three of them, broadest to narrowest:\n\n- `~/.claude/settings.json`: global, every project\n- `.claude/settings.json`: this project, checked in and shared\n- `.claude/settings.local.json`: your personal overrides, gitignored\n\nThe interesting part is the `permissions` block:\n\n```json\n{\n \"permissions\": {\n \"allow\": [\n \"Bash(git add:*)\",\n \"Bash(git commit:*)\"\n ],\n \"deny\": [\n \"Bash(git reset:*)\",\n \"Bash(git checkout:*)\",\n \"Bash(rm -rf:*)\"\n ]\n }\n}\n```\n\nAllow the commands you'd approve every time anyway. Deny the ones that destroy work: resets, a checkout that clobbers a file you've been editing, `rm -rf`. There's never a moment the model needs to run `rm -rf` on its own.\n\nTwo things worth knowing about deny. It's not a hard wall, Claude can find another route to a goal, so a deny nudges it toward the less destructive path rather than making the outcome impossible. And you can't tell it to ignore a deny rule for one moment, deny means deny, so if you want \"block by default but let me override\" put that command in the `ask` list instead.\n\nThe caveat that matters: the deny list prevents accidents, not attacks. If the model really wanted to wreck your stuff it could work around these, so don't lean on it as a security boundary. Where it earns its keep is the \"oops, shouldn't have done that\" kind of mistake, and deny something once and Claude stops trying it every session.\n\nOne aside on git commit hooks, the kind that block a commit until it passes checks. I tried those and found them so annoying (my commit wouldn't meet the rule, so I just wouldn't commit, and ended up with giant commits) that I gave up. I'd rather not block a commit at all. If you want protection, put it on what gets deployed, or require it only for merges into `main`.\n\nYou'll also hear about the flag that skips all permission prompts. It's real and I use it, but only inside an isolated Docker container that can't reach anything sensitive. On your laptop with your real credentials, keep the prompts on and build an allow list instead. That's step one.\n\n## Building something real\n\nEverything up to here was setup, so let's actually use it on something. First `/clear`, always, when you change topics, so the old conversation doesn't pollute the new one.\n\n```\n/clear\n```\n\nI'm not going to spec out a giant project on camera. We'll do a small V1: a media-processing app that takes a local video, transcribes it, and generates diagrams from what's being explained (actual mermaid diagrams, not screen grabs), plus a little HTML page to browse the results. Wrapped as scripts and a skill, run locally, nothing uploaded.\n\nThe trick with a spec is to not let it write the whole thing at once:\n\n```\ncreate a spec for this. don't write the full thing yet, go back and forth with questions first.\ndo external research on the tools we'd need before recommending anything.\n```\n\nMaking it research first anchors the answer to what people are actually using now, instead of whatever it half-remembers. Then it asks its questions and I answer: local video files, transcription with something offline like whisper or whisper.cpp, no API keys, mermaid for the diagrams (renders natively in Obsidian, GitHub, and Claude).\n\nWhile it works you'll see little tasks pile up at the bottom marked general purpose. Those are **subagents**, Claude spawning another Claude to go do a focused job. The reason to care is context: a subagent reads the fifty files or does the research in its own separate chat and hands back just the conclusion, so your main conversation stays clean. Claude reaches for these general-purpose ones on its own when a task calls for it, and you can also just tell it to delegate something to a subagent.\n\nTwo things showed up while it ran. `shift+tab` cycles the mode under the prompt, and auto mode is one of those modes: it uses a classifier to auto-approve the safe prompts, a gentler middle ground than the skip-everything flag. And `/resume` picks a past session back up where you left off, which is how I ran this one overnight and came back to it the next day.\n\nThis is where isolating Claude pays off. When it has to stop and ask me something every minute, I can't shift my focus to anything else. When it's boxed in an environment where it can't break anything, I can fire off a task, let it run for two or three hours, and review the whole thing at the end.\n\n## Verifying its own work\n\nNext day, I opened the repo in VS Code to see what it built. It named the thing VidGraph: drop in a video, get a transcript plus AI-drawn mermaid diagrams, transcription running about 6x faster than real time, fully offline.\n\nOne detail I liked: on a test video the audio said \"root handler\" but a frame showed \"route handler\", and because the tool peeks at video frames and not just the audio, it caught the right spelling. That's the whole reason to look at the frames and not just the transcript, and it happened on the very first test.\n\nThe gap was verification. It drew a diagram but couldn't confirm the HTML page actually rendered it, \"that's the only thing I couldn't check myself.\" So I wired it a browser:\n\n```\nyou can use Chromium through Playwright to open the page and verify it visually. do that.\n```\n\nIt ran the browser from a scratch directory so nothing landed in the project, confirmed the render, and offered to save that as a reusable `verify-hub.sh` the pipeline runs every time. That's the pattern I keep coming back to: push effort off myself and onto the agent. I'd rather it run long and hand me something that actually works than stop early and tell me it hopes the thing works but didn't get to check.\n\n## Hooks\n\nSo far everything has been instructions, and instructions get skipped now and then. A **hook** is code that ties into Claude's loop at fixed points, so unlike a CLAUDE.md rule it just runs every time, kind of like middleware in a web request.\n\nThere's a list of events, but the useful ones are PreToolUse and PostToolUse (before and after Claude runs a tool) and Stop (when Claude is about to finish a response, which can send it back to do more before it's allowed to end the turn).\n\nFor VidGraph I had it add a PostToolUse hook that validates every mermaid file the moment it's written, so a broken diagram never slips through. Hooks live in the same `settings.json`. To prove the wiring first, it started the hook off just echoing \"fired\" into a file every time it ran, then swapped that for the real validation:\n\n```json\n{\n \"hooks\": {\n \"PostToolUse\": [\n {\n \"matcher\": \"Write|Edit\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \".claude/hooks/validate-mermaid.sh\"\n }\n ]\n }\n ]\n }\n}\n```\n\nThe `matcher` picks which tool fires it, here only `Write` or `Edit`. The `command` is a script, not a prompt, whatever you can run from a terminal, and what it writes back gets fed to Claude.\n\nA newly added hook only goes live once the settings get reloaded. It worked for me because `settings.json` already existed when the session started. If you add one and it seems dead, run `/hooks` (which also lists everything wired up) or restart to reload. The [hooks docs](https://code.claude.com/docs/en/hooks) have the full event list.\n\nNavigating hooks in the menu is a little clunky, so I usually just ask Claude what hooks are active or read the file directly.\n\n## MCP\n\nLast piece, and I'm only going to touch it briefly since it really deserves its own lesson. **MCP** is basically APIs built for AI. A plain API is a bunch of endpoints, an MCP server wraps those with the extra context an LLM needs, so each tool comes with built-in documentation telling the model what it does and when to use it. Databases, browsers, other apps, if it has an MCP server, Claude can drive it.\n\nInside a session, `/mcp` shows what you've got connected:\n\n```\n/mcp\n```\n\nI connected my own platform, Course Catalyst, which exposes 72 tools, roughly one per API endpoint. So from the same terminal I build in, I can tell Claude to publish to my live site:\n\n```\ntake the joins video, create a page at /joins with the video embedded and a code sample below it,\nusing the course catalyst MCP.\n```\n\nIt pulled the block types it needed off my site (a video block, an image block, custom HTML, and rich text), uploaded the video, and published the page. That upload path is built into the MCP and described there, so any client knows how to do it without me explaining it. One snag it hit: an SVG image wouldn't render, so it rasterized to PNG, and that's the kind of fix I'd fold back in to the skill so it never has to think about it again. Turning a repeated step into a script is always the goal, it saves a pile of tokens versus re-figuring it out every time.\n\nWhen you want to connect your own, `claude mcp add` wires one up in a line, and the [MCP docs](https://code.claude.com/docs/en/mcp) walk through servers you can try in a minute or two.\n\n## Where to go next\n\nThat was a tour of the different pieces of Claude Code and the workflows I lean on. We barely scratched the surface with the app, the real work from here is iterating on it, adding tests, keeping the quality up. But if you can do what we did in this video, you've got a working knowledge of Claude Code and you're ready for the more intermediate and advanced stuff. I go a lot deeper on the whole system, the operational side of running software and a business on this, in the [Agentic AI course](https://codebreakthrough.io/agentic-ai). See you in the next one.",[],[],"d0215d9b-52f2-4243-85cd-f0756d554d3e",3515,"claude-code-introduction-full-crash-course-1-hour","Claude Permissions - This will change the way you use Claude",12,"## Timestamps\n\n- `00:00` - Intro\n- `01:46` - Permission Options\n- `04:12` - Classifier Blocks\n- `05:40` - Bypass Permissions\n- `09:52` - CLIs\n- `13:22` - What's Next?\n\nThese are the notes for the permissions video. The exact commands and the Docker isolation setup are all here so you can follow along.\n\n## The problem\n\nYou've probably been in the spot where Claude Code asks permission for the most basic stuff. It's irritating, it breaks your flow, and it means you can't run anything autonomously, you're checking in every couple minutes to see if it's waiting on you. Great for beginners, gets old fast.\n\nAllow and deny rules are the next step, but they don't cover everything that can come up, so they still block really productive work. If I want an agent to run for a long stretch on its own, I need more than that.\n\nClaude has more permission modes than you've probably used. Getting past this blocker, Claude not being able to run on its own, is the first step to building out large chunks of an app. So the goal is to give Claude the freedom to run autonomously without letting it destroy your system, your personal life, or your production servers.\n\n## The modes\n\nWhen you run Claude, the permission mode shows at the bottom. Out of the box you get read-only, and you approve each edit. Toggle modes with Shift+Tab.\n\nThe mode that reviews every action is called `manual` in the CLI. Shift-tabbing you'll probably see auto mode show up, but you won't see bypass permissions, that's not there by default. And if you don't even see auto mode, you have to launch into it:\n\n```bash\nclaude --permission-mode auto\n```\n\nThere are requirements for auto mode to be available, and they'll change over time, so check the [permissions docs](https://docs.claude.com/en/docs/claude-code/iam) rather than trusting a specific list from any one video.\n\n## Saving permissions between sessions\n\nWhen you say \"yes\" or \"allow all edits during this session,\" that only lasts for the session. Close Claude and reopen, and they're gone.\n\nIf you want to keep them but dump your context, use:\n\n```bash\n/clear\n```\n\nThat wipes the conversation but keeps the permissions. To keep them for good, write them down permanently in your settings.\n\nThose allow and deny rules are boundaries. For example, you can block `git reset --hard`. But treat them as accident prevention, not a wall against a malicious AI, it could find a way around a specific command. They stop the \"whoops\" moments, which is usually what you need.\n\n## Auto mode\n\nAuto mode allows most things by default. Under the hood a separate classifier model reviews actions before they run and blocks anything that escalates beyond a plain request. Anything dangerous still gets a prompt, and so do command substitutions, backticks, and process substitutions. Mostly it just nudges Claude to keep working instead of stopping to ask clarifying questions.\n\n### What auto mode blocks\n\nBy default it trusts your working directory and the remotes that were configured when the session started. A remote you add or repoint mid-session (`git remote add`, `git remote set-url`) is NOT trusted, and everything else is treated as external until you set up trusted infrastructure.\n\nSo the risky stuff is blocked, roughly:\n\n- downloading and executing code (curl piped into bash)\n- sending sensitive data to external endpoints\n- production deploys and migrations\n- mass deletion on cloud storage\n- granting IAM or repo permissions\n- force pushes (which can drift your migrations away from your actual database structure)\n\nThere's a full list in the docs. The point is it lets you do the safe things and blocks what's likely to hurt. I ran a full feature build in auto mode with zero prompts and no issues. That's your first real unlock.\n\n## Bypass permissions\n\nThe next step is launching with dangerously skip permissions. It's called `--dangerously-skip-permissions` for a reason, so pay attention, this is the one that can delete your production database and go \"oopsies, my bad.\" With it on, Claude will do whatever, post data, run anything risky, because you told it it could.\n\nSo when would you want this? I just assume the worst case. If the AI went off the rails and tried to delete all my code or wreck the project, what could it actually do? If the answer is \"a lot,\" then it's not set up right.\n\nThe fix is to isolate it. In the video I'm running bypass on this machine without a container, pushing the limits, but this is mostly a recording machine with nothing sensitive on it. Even then there's real risk, because I'm connected to a live production environment through MCP, working with production data for my own site.\n\n## Isolating in Docker\n\nBest move is to have Claude build the isolation for you:\n\n```\ncreate any Docker files (Dockerfile, docker compose), whatever you see necessary for my project.\n```\n\nOn one of my node projects I tied it to `npm run cc`, then had `cc1`, `cc2`, `cc3` for running multiple instances that share the same repo and the same Claude config. That sharing is intentional. The catch is the config lives both inside and outside the container, so you have to make sure nothing sensitive is in it. The big thing to pull out is any MCP connections, since those tie straight to production data.\n\nThe setup I described to it: multiple instances share the same config and login at the REPO level, so the container doesn't have to deal with it. The container just mounts the directory, and you can run inside or outside of it.\n\nWhen it finished it gave me a `docker compose build` and a launch command, and I had it boil that down to a single command. Trust the folder, and you're in with bypass permissions on. You can read more about compose in the [Docker docs](https://docs.docker.com/compose/).\n\n## Keeping secrets out of the container\n\nWords of wisdom: don't put anything sensitive in the repo. No production environment variables. Use testing ones instead.\n\nTake Stripe. Keep the production keys out and use local/test keys for development. Then you can give Claude free rein over those, because there's no risk if it touches them. For databases, run them as separate containers that the Claude instances share, or let each one manage its own.\n\nSame idea for CLIs. If you've got `gh` for GitHub, or Vercel, or anything wired to production, keep it out of the repo. SDK credentials usually live at the user level anyway (something like `~/.aws/credentials`), which works out great, because inside the container Claude can't see them. It can't push, pull, or take over your repos. Not that it would, but I'd rather it just not have access.\n\nSo the workflow is: code INSIDE the container, then commit and push from OUTSIDE, where your git config actually lives. The container is basically a dummy working on the mounted code with no git credentials of its own.\n\nTo sanity check, I asked the running instance to look at my GitHub and AWS config, and it came back with \"neither CLI is installed in this environment,\" which is exactly what you want.\n\n## The MCP still connected inside\n\nOne thing to watch. Inside the container I still had access to the Course Catalyst MCP, which means I could still destroy all my real work. That's the biggest one to figure out how to split out.\n\nA couple options. You can strip the MCP connections out of the config the container uses. Or you can add a pre-tool-use hook that blocks execution of any MCP commands. Just know the hook stops Claude from invoking the tools, but the container is still logged in to your account, so it's not a full fix.\n\nAnd a small tip: if you just want to ask a question, tell it \"don't code.\" That keeps it from running off and building something when all you wanted was an answer.\n\n## Remote control\n\nYou can also drive this from your phone. Enable remote control (the RC command), it connects up to Claude, and then anything you type on your phone shows up in the session after a second. I do this all the time.\n\n## What's next\n\nThat's the two unlocks, auto mode and bypass permissions inside an isolated container. The details of how I structure my isolated containers for real projects go deeper than one video can cover, so I'll keep sharing those, and it's a big part of the Agentic AI course where we take this and actually build and deploy an app end to end.",[],[],"1a347425-efb9-4e9e-8b5f-20dd0f057dd4",835,"claude-permissions-this-will-change-the-way-you-use-claude","I Was Wrong About AI",11,"## Timestamps\n\n- `00:00` - Intro\n- `01:13` - You're the problem\n- `03:58` - How things changed with Agentic AI\n- `04:58` - The game changer - The Vault\n- `06:36` - How to learn more about using AI\n- `07:51` - Goal driven prompting\n- `09:25` - Using MCP\n- `13:22` - Running Operations Through MCP\n- `15:06` - What I believe now\n- `15:52` - My 3 Approaches\n\nI used to say AI was going to make developers worse.\n\nI meant it, said it on camera and everything. And I was partly wrong, so let me talk through where I actually landed. It turned out to be a fault in my approach more than a problem with the tool. It matters way more what you're doing with AI than whether you're using it at all.\n\n## You're the problem\n\nThe fear was that people stop learning the fundamentals.\n\nYou lean on autocomplete, take whatever it gives you, and never build a real picture of what's going on underneath. You get 80% of the way to something and don't have the skills to take it the last 20%, which is the hard part, polishing the bugs out and making it production ready. Then you're shipping code you can't explain.\n\nI still think that's a real risk. I'm not gonna pretend I made it up. I was just blaming the wrong thing.\n\nThe tool doesn't decide whether you learn. You do.\n\nSo I could use an AI tool and learn a ton in the process, and you could use the same tool and learn absolutely nothing. Someone who wants to coast is gonna coast. Before AI they copied off Stack Overflow without reading it. Before that they copied out of the textbook. I remember someone in college turning in a solution written in the wrong programming language, they'd grabbed it from somewhere and didn't even notice it wasn't the language the class was using. The shortcut has always been there. AI just made it quicker.\n\nSo lazy will be lazy, that part isn't on the tool. And it's not like the good code isn't real, I've seen it said that up to 75% of Google's new code is AI generated now. These companies aren't shipping slop on purpose, the difference is how it's being used.\n\nThe other side of it is what got me. If you actually want to learn, this thing is a really good tutor. You can stop on any line and ask why. Ask it the same thing five different ways until it clicks. Paste in an error and get a real explanation instead of a forum thread from 2013 that ends with \"nevermind, fixed it.\" And it reasons about your actual project, not some toy example, it'll trace a request from where it comes in to where it goes out, spot an edge case you didn't think of, point at the bug. That's the stuff I would've loved when I was starting out.\n\n## How things changed with Agentic AI\n\nWay back when ChatGPT first showed up I used it to build a little game, and it was a nightmare.\n\nPart of that was the models being nowhere near where they are now, but a lot of it was my workflow. One prompt didn't get me there, and every prompt after that just added new problems. I'm pretty sure that's exactly where most people bail and decide the whole thing is overhyped.\n\nWhat changed was agentic AI. Instead of sitting in a browser copy-pasting between a chat window and my editor, the agent could work on the files directly.\n\nThat was scary at first, it's changing stuff faster than you can read it, and early on I had it anchored to nothing, no rules, no boundaries, just kind of loose on my code. It also got better the longer I stuck with it, and a lot of that was just me getting better at driving it. I was treating it like a vending machine, put in a prompt, get a result. It's more of a skill you build up.\n\n## The Vault\n\nThe thing that actually flipped how I work was giving the AI a knowledge vault and specialized skills to drive off of.\n\nI keep all my architecture decisions and the important context about the project in a folder the AI keeps up to date as we go. Then anytime it does something I don't like, I don't just sigh and fix it, I do something with that. Usually I update a skill, since that's how I launch most of my agents, a designer skill, a build skill, whatever, each one carrying the specific context to get the result I want. Sometimes it goes in the vault instead.\n\nThat was the shift for me. Pretty much any time something went wrong I could improve the setup so it wouldn't happen again.\n\nAnd it wasn't one giant CLAUDE.md growing forever. It's specialized spots, the vault documenting the components I have available, a skill holding the actual workflow for building good software. So instead of \"hey build me this feature,\" the skill turns it in to: spec it out, research a few ways to implement it, ask me questions to pin down the spec, build it, add tests, then separately verify the whole thing works. Now there's a multi-step process and it's a lot harder for junk to sneak through.\n\nThat's just scratching the surface of structuring your repo, skills, agents, and hooks. I put everything I've worked out over the last six months building my own SaaS in to my Agentic AI course if you want the full setup.\n\n## Goal driven prompting\n\nThe next thing that moved the needle was goal driven prompting, and it's a little weird.\n\nI'd give it a goal I knew it couldn't currently do, and have it invent the path to get there. This is basically how I built the whole API and MCP layer for my software. Instead of \"add the ability to import contacts,\" I'd hand it the outcome:\n\n```\nI need to launch a campaign to my contacts, so get them imported in to Course Catalyst through the API. If you can't do it yet, build whatever's missing in the API so that you can.\n```\n\nSimplified example, but pointing it at the result instead of the steps worked way better than I expected. It forces the thing to think through the whole end-to-end workflow, because the task literally isn't done until the result happens. When you just list features you tend to come up with nice-to-haves, not the actual path.\n\n## Using MCP\n\nThe bigger shift was when it stopped living in a code editor and could get in to the accounts I already use.\n\nI could point it at the tools my business runs on and let it read and write real data, pulling notes out of Notion, reaching in to Kit and Stripe, writing straight to my own platform, Course Catalyst. If the end goal is getting everything on to Course Catalyst, it can go grab whatever it needs from wherever it lives.\n\n![MCP hub connecting to Course Catalyst, Kit, Slack, Stripe, Notion, and Gmail](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/lesson/2026/07/TPcnASlcUfgk.png)\n\nThat's when it stopped being fancy autocomplete for me and turned in to something that helps with the operations, not just the code. And the thing that pushed me to seriously invest in this was a big migration. I was moving a whole business off a few different platforms, and it wasn't just the easy stuff:\n\n- 600 plus lessons, with code blocks and formatting that had to survive intact\n- 30,000 contacts\n- years of sales and transaction history\n- email sequences and automations\n- landing pages\n- forms and lead magnets\n- coupons and discounts\n- everyone's product access and enrollments\n- all the images and video\n\nI started out doing it with scripts, and I had a working prototype, import the contacts, pick what products they land in, confirm, done. The trouble is a script can't reason. I had both platforms live at once, so the same contact existed on both sides, emails going out from one or the other, and it was way messier than copy data, paste data. When something didn't line up perfectly the script had no idea what to do and I was back to doing it by hand.\n\nSo instead I built a skill for the migration. It writes whatever scripts it needs, checks the data on both sides, and flags anything that looks off instead of just handing me a pass or fail. While it was in there it also caught spelling mistakes and clunky wording and cleaned up some of my lesson copy, without flattening my tone in to AI-sounding mush. And when something didn't have a clean one-to-one match, like a couple courses I'd archived, it didn't guess, it laid out the options (import these in to another course, or mark them unknown) and asked me. I just tell it to bubble up the concerns and check with me, and it does.\n\n## Running Operations Through MCP\n\nHere's a small one that still gets me. I can describe a whole promo in a couple sentences and it wires the whole chain together:\n\n```\nUsing my Course Catalyst MCP, draft a simple thank-you email (~100 words): an extra 20% off Agentic AI for anyone who's gone through my AI Mastery course, expiring Monday 11:59 PM ET, with the coupon code in it.\nMake a coupon for 20% off that expires then.\nDraft it to everyone enrolled in AI Mastery, minus anyone who already bought Agentic AI.\nBefore sending, send me a preview email and the count for the send (AI Mastery − people who bought = ?).\n```\n\nIt asks a clarifying question or two (which coupon, which tier), then I get the preview in my inbox and read it over. I built the MCP so it has to confirm the recipient count before a big send, just to force it to slow down. And I was careful with anything destructive, there's no delete-broadcast tool at all right now, so if something needs deleted I either soft delete it to a trash bin or go do it in the account myself.\n\nNone of that was a feature I sat down and built. I can chain together whatever I need, right when I need it, and invent the next variation on the fly.\n\n## What I believe now\n\nEvery couple months someone tells me software engineering is dead. I don't really buy it.\n\nMaybe the earlier version of it is fading and some new version is taking its place. That sounds like cringey garbage when I say it out loud, but the point is you adapt to the new environment, same as always. Does that mean you have to use AI for everything? No. Does it mean you should at least be open to it being useful for some things? Yea, I'd say so.\n\nSo where do I land. Use AI when it makes sense, don't lean on it as a crutch, and don't skip understanding what it handed you.\n\n## My 3 Approaches\n\nI bucket it in to three.\n\nIf it's something you understand well, let the AI do it for you. If it's something you don't understand and don't care to, because it's just not relevant to you, let the AI do that too. The dangerous bucket is the thing you don't understand at all that also really matters, that's where you don't want AI driving, you want to be in it.\n\nA few examples of what I mean:\n\n- a basic CRUD API layer is a fancier version of scaffolding, let AI generate it\n- a user interface you can check with your eyes, you don't need to know the exact CSS\n- processing payments, if you don't understand it and you're having AI build it, you've got a real problem\n\n> [!tip]\n> Not every detail is worth caring about. If something's easy to check, you don't have to know how it was built, you can just look at the result. I can open a page, see it looks right, and measure how fast it loads without reading a line of the CSS. As the tools get better I sweat fewer of those little details and put more of my attention on the higher-level pieces.\n\nThe trap is the stuff you can't just eyeball. AI will sometimes do the work wrong in a way that looks completely fine, nothing errors, it just quietly isn't doing what you thought. The person who catches that is the one who knows how the thing actually works.\n\nHere's where it bites. Say it tells me \"you've got an N+1 database problem\" and I go \"no idea what that is, fix it.\" That didn't actually solve anything, the same pattern is just going to show back up later, and even if I paste it in to a CLAUDE.md I skipped the part where I understand it. So when something like that comes up, treat it as a trigger to go do the research. Then next time you hit a table scan and awful performance, you already have a rough idea how to fix it.\n\n> [!tip]\n> A couple examples of what I mean. It'll happily write code that hits the database inside a loop, one query for the list and then another query for every row in it, which is the [N+1 problem](https://planetscale.com/blog/what-is-n-1-query-problem-and-how-to-solve-it). It runs fine while you're testing on ten rows, then falls over once there's ten thousand. Or it'll filter on a column with no [index](https://en.wikipedia.org/wiki/Database_index), so the database scans the whole table every time instead of jumping right to the row. Both look totally fine until the data gets big, and you only catch them if you know to look.\n\nFor me that means I don't sweat the UI much, as long as it looks decent and stays consistent. But data, money, authentication, that's where I put in the extra effort to really understand what's going on behind the scenes.\n\nI just don't see AI as the thing that ruins that anymore. Used right, it's been the opposite for me. Anyway, that's where I've landed for now. Ask me again in six months.",[],[],"67ad0f67-2ba3-4108-a631-b65bc57dfee4",1134,"i-was-wrong-about-ai","15 Years of Software Engineering Advice in 1 Hour",10,"## Timestamps\n\n- `00:00` - Intro\n- `01:09` - Disruption is fast – Adaptation is slow\n- `03:35` - Use AI enhanced development and learning\n- `06:55` - Find a mentor\n- `14:57` - Approach to learning\n- `15:39` - The Correct Approach to Learning\n- `22:22` - Learning is Painful\n- `26:15` - Use AI to enhance learning\n- `33:57` - Start building stuff as soon as possible\n- `36:08` - Challenges of Building Software\n- `39:10` - Short Circuit Skill Development\n- `41:56` - The Most Valuable Skill\n- `48:31` - Strategy to get results\n- `49:11` - Stop Worrying about Titles\n- `50:54` - Grow your Circle\n- `54:45` - Rejection\n- `55:42` - The Truth about Networking\n\nI've been building software and running my own business for about 15 years. These notes go with the video and cover everything I'd do differently if I was starting from zero today, basically letting you learn from my mistakes. Most of it applies whether you're a software developer, an app builder, or running a small online business, and a chunk of it is just how to get more out of your life in general.\n\n## Disruption Is Fast, Adaptation Is Slow\n\nIf you take one thing from this whole video, take this one, because it frames everything else. Disruption moves very fast, and adaptation is slow. When you're early on you might be on track, but if you're not keeping up with new capabilities and new approaches to work, you slowly diverge from the proper path.\n\nThis is a super common problem for people deeper in their career. You say \"I have 15 years of experience\", but you don't have the experience that actually matters today. That's how a senior engineer can get laid off and struggle to compete with entry-level engineers, if those entry-level engineers focused on the correct stuff. Someone brand new who put most of their effort in to whatever is disrupting the industry can beat someone with way more total skill, because they have the right skill.\n\nSo there's two ways to use this. If you're experienced, spend the extra time to keep up with what's new. If you're brand new, treat it as an advantage and aim your effort at what's in demand right now.\n\n## Use AI Enhanced Development and Learning\n\nHere's the thing I cannot wrap my mind around. Almost daily I get an email from somebody new asking \"what can I do to learn as fast as I possibly can?\" I answer: use AI agents to enhance your progress. And the response is \"whoa, I don't want to use AI because that's going to slow down my learning.\"\n\nSo let me get this straight. You asked what I would do in your situation, my answer is fundamentals plus AI enhanced development and learning, and you're refusing it because you've adopted the belief that AI will destroy your foundation. That's an issue with how you use it, not whether you use it. Refusing to touch AI until you're a senior developer just forces you in to the structure of people 20 years in who are failing to adapt.\n\nShould you know how to code? Yes. Should you understand the fundamentals? Absolutely, it's what I recommend people start with. But pair that with AI. I've been using agents pretty much every day for the last 6 months, and the amount I've learned in that time is comparable to a couple years of studying on my own. There are times you write everything by hand, times you let agents write code, and times you use agents purely to check your understanding, your architecture, bugs, security. It doesn't make your software worse, it makes it better.\n\nIf you want to speedrun this part, that's what my [Agentic AI course](https://www.codebreakthrough.com/agentic-ai) is: AI enhanced software engineering, applied from building my own apps, without ending up a vibe coder who has no idea what they're doing.\n\n## Find a Mentor\n\nWhen I started I was completely on my own, wasting time on YouTube trying to figure stuff out. No AI back then either (I feel like a boomer saying that). Today I use AI to guide my learning, but for any important architectural decision I still check with people more experienced than me, because there's something neither AI nor solo practice can replace: experience that took years to develop.\n\nFind that person as early as possible. If you can't find them, first off, you probably haven't tried very hard, go network on LinkedIn. Person-to-person is still the biggest value there is for growing your skill, your network, and your opportunities. Something as simple as messaging a book author \"hey, I read your book, good stuff\" gets responses more often than you'd think.\n\nIf you truly don't have that person yet, the substitute is content about applied experience instead of tutorials: engineering blogs and podcasts. When I was getting in to cryptography I found the [Zero Knowledge podcast](https://zeroknowledge.fm/) and learned from how actual practitioners thought through problems, what they found valuable, what issues they were hitting. When I was learning NoSQL, [Discord's article on how they store messages](https://discord.com/blog/how-discord-stores-billions-of-messages) showed me why they actually needed that database, and the why is exactly the part that's hard to learn as a beginner.\n\nThink of it this way. Tutorial hopping picks up little coins of knowledge, and stacking coins takes forever. One person with real experience is a treasure chest sitting right in front of you, and most people are too busy collecting coins to open it. At my first job I pair programmed with a guy way better than me, and he irritated me constantly, \"no, rewrite it from scratch, do it this way.\" Looking back, that was the most helpful time in my whole journey, because I finally learned why we do certain things.\n\nAnd notice this pairs with the first point instead of contradicting it. Adapt fast AND learn from experience. Two sides of the same coin: take in what's new, and take in what's already been learned, from whoever has it.\n\n## The Correct Approach to Learning\n\nBuild a broad general foundation, then specialize. If you spread yourself thin trying to be good at everything, you end up average at a bunch of stuff and great at nothing. The foundation part means scratching the surface of a lot of non-overlapping areas, networking, databases, backend, desktop apps, low-level programming, you get 80% of the benefit from a little time in each.\n\nThe two failure modes are not knowing what to specialize in, and topic hopping. When I started I was all over the place, jQuery one day, Angular the next, then Google Apps Script, whatever I felt like that day. The efficiency of this was trash. I never went deep enough in anything to discover new things, I always stopped right where my existing knowledge ended.\n\nThat's why I recommend end-to-end flows, point A to point B without wandering off the path. It's why I'm a fan of courses. When I had to learn React I watched a roughly 4 hour course in a single sitting. Did I know how to build everything in React after? No. But I could stack deeper knowledge on what I'd just learned, and I had the video to anchor back to.\n\nFor programming languages: pick one, I don't really care which, and go as deep as you can. Learning loops in Python and then learning loops again in TypeScript feels productive, but you didn't learn anything new, you learned a translation, and translation is a low value skill you can pick up on demand. Instead of learning the same thing twice, learn the differences between the languages, that's the actual skill. In my Java class in college I had never used Java, but I had used C, so I literally wrote my code in C and Javaified it with minor translations.\n\nThe same trap exists with AI tools today. A little ChatGPT, a little Codex, some Claude, some Cursor, and you call yourself an AI power user while never having written a skill or created a subagent. I picked Claude Code and got really good at that one thing, and it translates to the other tools easily because the patterns are similar, you just need the diff.\n\n## Learning Is Painful\n\nIf you're learning something and thinking \"this is hard, I don't really understand\", that's a good thing (unless it's way too difficult). If it felt super easy and you walk away with nothing concrete, it felt like learning, but you were just exercising your brain on stuff you already know.\n\nDeep learning for me has always taken a lot of focus, cross-referencing, and note taking. I do have a passive mode too, podcasts and entertainment type content, but the deep kind is more painful than fun.\n\nQuick message to companies and recruiters while I'm here: if a developer is really good but hasn't used your very specific software that nobody cares about, that doesn't matter, they can pick it up, since they're already deeply experienced in other stuff.\n\n## Use AI to Enhance Learning\n\nAt one point I caught myself thinking \"I don't really need these AI tools, everything I use works fine.\" I forced a full mindset shift instead: build an app, and everything I can do with AI, figure out how to do it well, not sloppy. Here's what came out of that for learning specifically.\n\nCreate a knowledge vault. A folder of markdown files about whatever you're studying or building, as reference for you AND the AI. Have the AI structure your thoughts and correct anything wrong in your notes.\n\nWrite your own skills. A skill is basically a reusable prompt you can invoke like a function. Some I'd write as a learner: research, code translation (how would this look in other languages, and specifically how are they different), and design alternatives. Alternatives is the most valuable one, because the biggest challenge with modern learning is siloed concepts. If you're studying object-oriented programming, a good alternatives skill would surface that some languages organize around functions instead, some are trait or interface based with no formal classes, some have multiple inheritance and some don't, and maybe you don't need OOP for your problem at all. You stop thinking \"this is the way it's always done\" when other people are doing it a completely different way.\n\nGenerate runnable examples for things documentation glosses over. Docs say \"here's what happens on overflow\" and you just trust it and move on. Now you can have AI produce a small example you actually run, and it goes deeper in your mind. Concurrency is a great case: three tasks run serially, or in parallel where you wait for all of them before printing done, or fired off while the code continues and they finish after. Ask AI for code that produces each behavior, real world examples of when you'd choose each one, and the pros and cons, instead of one isolated solution.\n\nIt can also quiz you, write tests you have to make pass, and review your notes for flaws in your understanding. I use the same trick in app development, fanning out multiple agents to show me different frontend approaches, introducing randomness to get ideas outside what I'm currently looking at.\n\n## Start Building Stuff as Soon as Possible\n\nNot just through work, your own projects. And don't let them stay basic. A calculator or todo list to meet the language is fine, but then build something that actually takes time, effort, and thought, and keep working on the SAME app over time. My biggest downfall early on was tinkering with something for a day, getting bored, and moving on.\n\nEventually I decided to build a cryptocurrency from scratch in Rust. How does a wallet work, how does the encryption work, how do transactions move, how do I build out the CLI. Nobody was going to buy Currycoin, but it was exciting, and within about a week of starting, a company reached out looking for a Rust developer. Nothing to do with crypto, but I could show I'd built something more complex than what you finish in an afternoon. That became my last senior software engineering role before I left to build my own business.\n\n## Challenges of Building Software\n\nBuilding your own real software gets you a product mindset, and I'd say that's one of the biggest values you can bring anywhere: what features do we actually want, what do they actually need, what do they cost to implement, what will people actually pay for. AI can crank out CRUD apps and more, but piecing everything together in to a valuable product with real users takes higher level thinking, and that's the part companies care about.\n\nIf you're in to mobile, build an app, put it on the app store, get reviews, get users, figure out monetization, advertising, marketing, sales. You'll work with real data, real customers, support, security, and most importantly you'll be challenged and hopefully motivated. It helps a lot to be in groups or forums with people doing the same thing, doing all of it alone is a lot.\n\n## Short Circuit Skill Development\n\nSome skills are almost impossible to have as a brand new developer, and running a real deployed app short circuits them. If everything you've built runs on your local computer, hiring you is a risk, not because you can't code, but because you can't code in the context of what the company is doing, which is production software.\n\nReal data means thinking about where the data lives (GDPR, privacy concerns, medical data), latency to your users, and live migrations. Say you need to change your data structure but real accounts already exist on the old shape. How do you migrate without corrupting anything, while users never notice, while you keep shipping updates? No tutorial gives you that, and knowing it is 100 times more valuable than local prototypes. If I started again I'd immediately pick a project to push live and treat like a real thing: a domain, branding, actual customers, everything a real company does.\n\n## The Most Valuable Skill\n\nResourcefulness. Being able to figure anything out, whether on your own, with AI, or by working with other people. Certain mindset beliefs cap your potential before skill ever enters in to it, if you assume you can't do certain things, that alone becomes the box you have to live in.\n\nNow, my little university rant. I ended up getting a traditional CS bachelor's myself, so I'm not purely trashing it, but the mindset coming out of these programs is rough: \"I have the degree, jobs will be handed to me.\" If you came to me for a developer job and led with your bachelor's, I'd assume the only thing you're really good at is drinking beer, because so many people come out of university unable to code that odds are you're not the exception.\n\nSo when people say AI is destroying the junior market, there's probably some truth to it, but the deeper problem is the degree pipeline not preparing people for real work. What's taught in university right now lags what you need right now, the same disruption-versus-adaptation gap from the beginning. And I suspect the \"don't use AI, it'll hurt your learning\" belief gets drilled in there too, possibly because AI is a real threat to universities in general.\n\nBack in one of my classes, the guy next to me watched Twitch streams during lectures. Paying money to be there, watching people play video games. That approach would hurt him just as much today, except now he'd get to blame AI for it instead of his own discipline. Whether you get the degree is your call to weigh, but either way, imagine spending those same 4 years also building your own real stuff. You'd come out with more real world skill than most people around you.\n\n## Stop Worrying about Titles\n\nAround 6 years ago it felt like if you weren't getting in to Google, Amazon, or Apple, you were a failure who didn't deserve to be in software engineering at all. There are literally thousands, if not millions, of companies you can apply your skills to, and way more roles than just \"software engineer\".\n\nI was so tied up in that title, but my personal strengths kept leading me to other kinds of roles: developer relations, leading technical workshops, helping with marketing around technical products, and pure engineering at times. The last offer I got was $240K, with $180K base, to make technical videos from my basement. Opportunities like that are equally as good, if not better, than a lot of the engineering roles out there. And pure implementation roles are becoming less common anyway, with AI engineering variants showing up. Open your mind a little about the company and the job title.\n\n## Grow Your Circle\n\nBreak out of your network as quickly as you can, toward people beyond where you are and where you want to be. The principle is you don't know what you don't know.\n\nFirst time I felt this: I was a cofounder alongside engineers who'd all come out of very high paying roles, and when salary came up I was like holy crap, I did not know those numbers were possible. Unheard of in rural Ohio, where my neighbor is a corn field and the best job around is the factory. Seeing it in real people is what let me push for higher pay later, because what's preventing me from doing the same?\n\nPricing is where this shows up clearest. I had a service I charged $500 for and decided to try $1,500. Three times the price, felt insane, gave me real anxiety to submit it. They said yeah, that's fine, no biggie, didn't even blink. I undersold myself even at 3x. I did that multiple times and it added up to around $28,000 over a month or two, right out of high school. Today I wouldn't even consider doing that work at $1,500, because my network and mindset expanded to where that number looks irrationally low.\n\nSo the common advice is to push through discomfort and charge more. The real breakthrough is expanding your comfort zone until the number isn't wild anymore, and you do that by being around people who quote it without thinking.\n\n## Rejection\n\nEarly in my career I worried about everything, to the point it affected my performance. I noticed the less I cared about something, the better I would perform, because caring meant overanalyzing, anxiety, and self-sabotage. Not the actual problems, the worrying about them.\n\nThe fix, as far as I've found one, is practice. Sales, negotiating, pushing back on demands, all the stuff I used to avoid. I've built up a tolerance to discomfort by doing uncomfortable things on purpose, and here's the secret, I'm still always uncomfortable. I just do it anyways. These turned out to be some of the greatest unlocks for getting more out of life, which is why I'd start collecting those reps in year one instead of year ten.\n\n## The Truth about Networking\n\nI saved this for last on purpose. As AI takes over more of everything, a lot of people conclude everything should become AI. For human-to-human interaction, I'd argue the exact opposite: go MORE human.\n\nApplying to jobs with AI-written cover letters, sifted by AI screeners, has made the whole thing feel inhuman, which means walking up to somebody and saying \"I'd love the opportunity to work on your team\" or pitching a product face to face stands out more than it ever did. Automate the routine stuff, sure. But for high value opportunities, bring your actual human self and go the extra mile. In my own business, the one-on-one work and the services I provide are things I will not hand to AI, going above and beyond there is exactly what differentiates me going forward.\n\nSo networking 2x, human touch 2x, WHEN appropriate, and automation everywhere else.\n\nThat's pretty much it, advice to my earlier self, framed as if I was starting today. If something resonated, leave a comment on the video and let me know.",[],[],"fff99667-b64d-429b-84e4-5a957546547d",3542,"15-years-of-software-engineering-advice-in-1-hour","These 60 Minutes Will Change the Way You Build SaaS",9,"## Timestamps\n\n- `00:00:00` - Introduction\n- `00:02:49` - What Am I Building?\n- `00:06:31` - My Target Market\n- `00:07:27` - Email Marketing\n- `00:10:59` - Why I Decided to Build My Own SaaS\n- `00:18:07` - Types of App Developers\n- `00:20:30` - Finding a Problem\n- `00:22:34` - My Problems\n- `00:29:30` - Feature Differentiation\n- `00:33:18` - Scope Creep\n- `00:36:33` - Technical Challenges\n- `00:41:33` - Decisions\n- `00:44:19` - Customer Acquisition\n- `00:46:43` - Course Catalyst for Devs and SaaS\n- `00:49:23` - Agents and AI\n\nI've posted very little on YouTube over the last 7 months, and that's because I've been building my own software.\n\nHere's where I'm at with it so people know what stage this is coming from: the software is built and I have one paying customer (two if you count me, since I run my own stuff on it). That's it. So this isn't me teaching you everything I know about SaaS, it's more building in public, the stuff I ran in to and the stuff I'll probably run in to as it grows.\n\nIt's worth knowing the difference between users and customers too, because they are not the same thing. My app is in early access and already has thousands of users, but one paying customer. When you see people on Reddit talking about hundreds of users, or even lots of paying users, that could be free accounts or a $7 one time purchase, which doesn't really add up to much. My one customer was a purchase in the thousands of dollars.\n\n## What Am I Building?\n\nI'm Caleb, I've been making YouTube content and doing software engineering for my entire adult life (I think my first videos were on database design when I was 15 or 16). I did co-found some software a couple years back, but a project at this scale entirely on my own is a big step up.\n\nI definitely underestimated it. I figured a month, maybe two to get it polished. I'm 7 months in and I've worked way more hours than I planned on.\n\nIf you're 3, 4, 5 months in to building something and you haven't put it in front of anyone, there's a really good chance it never gets out there unless you decide to finish an MVP and ship it. It's never going to feel ready. Around month 3 or 4 I decided I was getting a customer whether the product was done or not, because I could see it going south otherwise. So scope it small, something you can build in about a month, and add features from there.\n\nThe product is **Course Catalyst**. In chemistry a catalyst speeds up a reaction, so the idea is getting a course out there fast to start collecting leads and making sales, pushing people to mid-ticket offers or to book a call for higher ticket ones, and doing all the email and lead nurturing in the same platform.\n\nIt's not only for courses anymore, and that was the biggest scope change along the way. It works for coaching programs, for SaaS, for creators who just want to grow a list. I might rebrand at some point, but for people selling courses the name makes it pretty clear what it's for, so I'm leaving it for now.\n\n## My Target Market\n\nA big one is anyone running an online coaching or mentoring business. How people learn online keeps changing, and a lot of programs are hybrid now, modules plus some group or one-on-one components. They need to host modules and downloads, run nurture emails, and onboard people who join. Coaches are usually good at coaching, and might be good at sales, but they're often pretty terrible at content and marketing, so this is a place for the program and everything before it (free course lead magnets, email marketing, and so forth).\n\nThe other one is SaaS. When someone signs up for your app, that contact should be on a list you're nurturing, pushing them back in to the product or upselling them to a higher tier or another product. A lot of developers skip this part completely. They get free users and then do nothing with them.\n\n## Email Marketing\n\nCourse Catalyst does email natively, not as an add-on or an integration to some other email platform. I put a lot of work in to deliverability, which just means reducing how often email ends up in spam, through how the emails are structured, a bunch of checks, and the way authentication is set up.\n\nOn the list side, providing value to subscribers regularly doesn't have to take a lot of your time, and you can pretty regularly get a 35 to 45% open rate or higher depending on how aggressively you clean your list. That's 4,000 or more people opening your newsletter out of 10,000.\n\nI think of email as the most owned platform. On YouTube or Instagram or LinkedIn you're kinda renting the space, and an algorithm change can take your engagement away. It can happen with email, but it's much rarer, and usually comes down to your domain getting reported for low quality emails. And people open their email to read updates, get coupons, and make purchases, not to be entertained by 10 second videos, which makes it a really good place to sell.\n\n## Why I Decided to Build My Own SaaS\n\n**Software as a service** just means software people subscribe to, so you build monthly recurring revenue.\n\nI've enjoyed building software my whole life, and being able to create something other people can't has always felt a bit like a superpower. I've also always had the entrepreneurial thing going, and I've never loved the 9-5.\n\nMy last job was senior software engineer, writing Rust. I quit, turned down another really good offer at a different company, and went all in on YouTube, courses, and a software engineering mentorship program. The mentorship helped a lot of people land senior roles, get promoted, or get hired after years of not being able to get interviews, and I'm really happy with that.\n\nBut after 6 months, a year, all I was really doing was mentoring. I wasn't building my own stuff beyond what I made for tutorials, and it felt like I wasn't doing what I was preaching. A lot of the people I worked with wanted software engineering jobs, and in my soul I didn't even want one myself. Over 50% of the mentoring ended up being mindset work too, bad thought patterns, study habits, consistency, which was way beyond what I originally planned for the program. I liked it, but it wasn't what I wanted out of my life.\n\nThis app had been an idea for years. I'd scoped it out and talked to people about it and never jumped. The biggest reason was that software takes a lot of time and it's hard to make income from it. Marketing, sales, and product market fit are the hard parts, and you can build the best software in the world and if it's not something people have enough pain about to pay you, it doesn't matter. Probably some fear too, because it's a lot easier to think you have a good idea than to build it and find out. People running their own businesses kept asking me why I didn't just build my own stuff, and eventually I sat down one day and said we're starting today.\n\n## Types of App Developers\n\nPeople usually land in one of two buckets.\n\nThe idea people: \"I have an app idea that will make millions, can you build all of it and I keep 90%?\" And the coders who can build anything but can't come up with an idea or execute unless someone hands them the task. They'd be perfect for a regular software engineering job.\n\nI talk to developers all the time who say they can code but don't know what to build, and to people with an amazing idea who are never going to actually build it. If you're mostly in one bucket, find someone from the other one to pair with (co-founder, founding engineer, whatever you want to call it). If you're going solo you need a bit of both. I'm okay at ideas and decent at coding, not a genius at either, and so far I haven't hit a roadblock I couldn't get through on my own, so I'm staying solo for now.\n\n## Finding a Problem\n\nMost software solves a specific problem for a specific type of person, and this is the hard part, because you don't know ahead of time if people will pay for your solution.\n\nMy thinking was, if a company thinks it's worth paying me this much to write code, there's got to be more money in building the software myself.\n\nThere are two good ways to find the problem:\n\n- ask people or do research\n- your own pain\n\nI went with my own pain and did very little user research. I think that's fine in my case because I have years of experience with this exact pain, and if I solve my own problem I can probably solve it for people in a similar spot.\n\n## My Problems\n\nI've run courses on Kajabi, tried Teachable and Podia, used marketplaces like Udemy and Skillshare, and had courses on more exclusive platforms like Course Careers and O'Reilly. Here's what one free course sale looked like on my own site:\n\n![The old marketing stack](https://course-catalyst-pull-zone.b-cdn.net/photos/ZDEzNWM0YjEt/youtube-notes/2026/07/pHeVaN3nx4fd.png)\n\nSomeone enrolls in a free course. It's free, but it's a **lead magnet**, you get the product in exchange for your info. That enrollment triggers Zapier (automation software that connects different tools), which enrolls them in a Kit sequence. Then for the evergreen funnel with deadlines, a separate deadline service holds a personal deadline for that one person, so the offer expires a certain number of days after they signed up.\n\nAnd that whole structure was duplicated for every lead magnet. A back-end engineering roadmap, a free preview of my fundamentals course, a free React course, probably 10 or 15 of them. Too many, but that's not the point. Each one needed its own setup on the Kit side and its own automations, and it was very easy for things to fall through the cracks. If any piece paused or disconnected, the whole thing stopped working the way you'd expect.\n\nThen there's the cost, roughly:\n\n- course platform, maybe $300 a month\n- Zapier, maybe $60\n- email, maybe $250\n- deadlines, maybe $99\n\nSometimes I was paying twice on purpose, because the course platform had email but it was atrocious, so I moved it to a better tool.\n\nThe bigger problem was the gap. The deadline was tied to the email, not to their course account, so the course platform had no idea the deadline existed. And the sequences counted days forward from signup, 1 day after, 2 days after. It works, it's what I did, but it's backwards when you're working toward a deadline. I think in 5 days before, 4 days before, 3 days before.\n\nSo the idea was to collapse all of that in to one thing. In Course Catalyst you have the product, the contact, the offers given to that contact (that's the deadline), and **deadline-based sequences** written from the deadline backwards: an hour before, 4 hours before, a day before, 2 days before, back to when they enrolled. The enrollment triggers are cleaner too, any free enrollment, any brand new contact, or enrollment in one specific product. Replacing that stack saves me almost a thousand dollars a month in random software.\n\n## Feature Differentiation\n\nFeatures on their own are weak differentiation, especially now that AI can help anyone build features. You usually need something more:\n\n- how fast you develop\n- the community around the app\n- service and support\n- data other companies don't have\n- economies of scale, buying in bulk to get prices a smaller competitor can't match\n\nAs the small guy, you can't win on scale, but you can give every individual customer white glove service, which a big company probably won't care to do.\n\nBuilt-in deadlines are a feature very few course platforms and marketing systems have, and I'm not confident that'll always be the case. But because the deadline lives in the same system as everything else, I can put it anywhere: on the student's library page showing which offers are available to them, or in the course player saying you can upgrade to the next tier at a discount and here's how much time you have left. You can't really reproduce that with an external deadline tool plugged in to another platform, because that tool can't give anything back to the platform. So even if you can plug features together with an integration, you don't always get a one-to-one match with something built in natively.\n\n## Scope Creep\n\nTry to get your app out within about 3 months, and try not to go past 6. I don't know the actual stats off the top of my head, but the further past 3 months you go, the more likely it never gets finished or never reaches a customer.\n\nThe biggest thing that stops you is **scope creep**. You start with something cute, built-in deadlines, then add features that build on it, and eventually you have a monster that never gets out the door. I knew about this problem and even made a video about avoiding it, and I still did it. Sometimes building something exposes other features you could build, and sometimes building for a real use case shows you features you actually need.\n\nMy first customer wanted a community feature. I'd experimented with one and archived it on purpose to keep the MVP focused. But I also didn't want them leaving for a competitor.\n\nWhat I'd recommend is to figure out what you do, and for anything you don't do, have a reasonable alternative ready. Right now I have some CRM capabilities, every product a contact bought, every lead magnet, every email they got, all in one spot. Emailing an individual directly or texting would be nice, but that's a lot to build, so in the meantime I point people to a specific CRM as the recommended integration.\n\n## Technical Challenges\n\nThe other reason apps take way longer than 3 months is you don't know what needs implemented until you build it. \"Set up a landing page and process some payments, no biggie\" hides a lot.\n\nI don't process payments natively, I don't think that would be wise as a one person show. It goes through [Stripe](https://stripe.com) (and a lot of the big players with their own payment systems are really just white-labeled Stripe). Someone hits buy, pays, and gets redirected to a success page. But what if they leave before that page loads? Or the payment succeeds on Stripe's side but your server fails to store it? That's what [webhooks](https://docs.stripe.com/webhooks) are for, Stripe also sends a request to your server, and you need handling where the redirect and the webhook can both run without causing a problem.\n\nEmail providers do the same thing for opens, clicks, and delivery data. Then you have to know the sender's behavior. Do they retry? What if your service goes down for a while, or you handled webhooks wrong for a stretch, and your database drifts out of sync with the provider? You need a way to get the data back in sync, even if ideally your webhook handling is resilient enough that it doesn't happen.\n\nA few more that came up for me:\n\n- storing videos, do you track the state server-side (uploading, processing, done, failed)?\n- analytics, do you build them in your app or use what the streaming service gives you for views and retention?\n- time zones. It's multi-tenant, so multiple businesses run on it. Do deadlines anchor to the main service, UTC, the tenant, or each user so everyone sees their own time zone? That one took me a lot longer to think through than it should have.\n\n## Decisions\n\nThe hardest part of building an app now is making decisions and designing a system that isn't garbage, way more than the coding. Google login, email and password, passwordless, which auth tool, and on and on. Every one of those decides whether the product is good and what the user experiences, and it's by far the slowest part.\n\nFor a lot of things you can just not care as much and pick one. For the important ones, instead of asking \"what do I choose?\", ask how hard it would be to undo. Most things can be undone, and if the cost is low, decide and keep moving. The sooner you make decisions, the sooner the bad ones show up, and that's when you have the fewest users and the least data to worry about.\n\nOnce you have real user data, changes get harder. A migration that changes the data structure might need a script to update real data, or you move the data to a new column, run off the new column, and sunset the old one once everything works.\n\nThis is a big reason I like having a few high-paying customers. If a breaking change hits, I can work with them directly and fix it by hand, instead of writing custom scripts and checking everybody's data across tons of accounts.\n\n## Customer Acquisition\n\nSince I have one customer, I'm obviously an expert here 🙂 It's a similar structure to what I've done with this content and my courses and coaching though.\n\nIt starts with a lead magnet, and I think a free course is the best lead magnet there is. It's great for nurturing, engaging, high value, easy to consume, relatively easy to make, infinitely scalable, and people usually want a lot of watch time with you before they buy.\n\nMy funnel:\n\n```\nfree course lead magnet → book a call → sales call → customer\n```\n\nI feed the top with social media, reels on Instagram with the free course in my bio, and later probably ads, plus inbound messages or follows to find business owners. My first customer actually found me organically because I was talking about mid-ticket funnels.\n\nFor a mid-ticket product, you'd swap the call for a purchase with a personalized deadline based on when they signed up, and the sales call becomes buying the product.\n\n## Course Catalyst for Devs and SaaS\n\nMost people who watch my stuff are developers, which isn't exactly the Course Catalyst customer, so I'm working on developer features: being the marketing platform for your software, and documentation. A lot of bigger software has a doc site or a learn site or an academy. The course player isn't just videos, it supports markdown, programming languages, embedded media, search, and it's easy to update through an LLM over MCP, so you could host your docs or examples there.\n\nI think the biggest challenge with developers is they're cheap, and they might not see the value in landing pages and product offers. Business owners, creators, and coaches are easier to justify because there's a clear path to more calls booked or more sales.\n\nI'm still trying not to market to everybody, though. Instead of splitting developer vs coach vs creator, I'm focusing on people who need digital products and want to do email marketing, so it's more about what they need than who they are. We'll see if that works.\n\nIf you want to check it out, it's at [coursecatalyst.com](https://www.coursecatalyst.com/elite). It's early access, so the landing pages might not be fully polished, but if you work with me directly I build everything out with you.\n\n## Agents and AI\n\nThis is basically the origin story of the app. I was making an AI course and was going to build a small iPhone app that would take a week or two, and then decided to finally build the app I'd been putting off. I documented a lot of that in the course: research on what stack to use, product differentiation, pricing strategy, and how to do customer support and service, since I wanted to pair it with a white glove service where I build out your products, landing pages, funnels, and deadlines for you.\n\nAt first it was about 50/50 AI and me coding by hand, and I read most of what the AI wrote. Anything sensitive or back-end heavy I stayed involved in, so I built the payment processing myself, while the UI I didn't care how it was implemented as long as it looked okay.\n\nThat went from \"this is cool, a pretty good prototype\" to really annoyed. It kept reintroducing bugs I'd already fixed and couldn't get past a medium level of complexity. I literally went back to coding pages by hand and almost restarted the app from scratch. Then I spent a lot more time learning agentic AI properly, which I should've done from the start, and things turned around:\n\n- building my own workflows, agents, and skills, and using hooks\n- converting as much as I could to static checks, TypeScript, Prettier, ESLint\n- orchestrating multiple agents for speccing features, research, implementing, verifying, UI design, and testing\n- using the right models for different jobs instead of the defaults\n\nNow on a bigger feature it might code for 3 hours and I review it against the spec.\n\nStart clean and enforce the rules from the beginning. My code base was sloppy from the early phase, with a ton of TypeScript issues that didn't break anything (implicit and explicit `any`s, unknowns I didn't want), so I spent a week going from garbage to high quality. I added a bunch of static checks, including custom ones to protect cross-tenant access, require every endpoint to define its authentication expectations and validation, and block certain unsafe database access patterns. Now it's very hard for the AI to write sloppy code in the repo, and everything is anchored in a vault describing the features and domains of the app. I go through the whole approach in [These 90 Minutes Will Change the Way You Use AI](https://www.codebreakthrough.com/products/63765398-fb1e?lesson=677ff8a2-c4e1).\n\nI also went mobile first. Every feature gets checked in the mobile preview in the browser dev tools before I build it out for desktop, and that alone sets you apart from a lot of complex apps that lag behind on mobile.\n\nFor the MCP server and the API, I did what I'd call outcome-focused implementation. I'd ask the AI to do something that wasn't possible yet, like \"import my Kajabi contacts\", and have it build the MCP and API endpoints needed to make it work, then deploy and iterate. So any workflow I can picture a customer using, I know the endpoints exist. Another one is drafting coupon emails to certain segments from Claude Code and having it send me a preview. The whole platform is designed to be AI native, so you can do everything through an LLM, and I already migrated all of my own stuff over to it using those same MCP workflows.\n\nNext for me is polishing and adding features, running ads for the platform itself (the pixel is already built in so customers can run their own), putting a lot more time in to YouTube, and getting new customers. I'm also playing with some micro SaaS ideas that could use the platform but be separate products, smaller projects that don't take 6+ months. More on that in the future.",[],[],"796fbf8c-25ae-4aea-b5f5-108d11d4aa9a",3669,"these-60-minutes-will-change-the-way-you-build-saas","Intro",8,"intro","Connect AI to Anything - Build your First MCP Server (Model Context Protocol)",7,"## Timestamps\n\n- `00:00` - Introduction\n- `2:49` - What does MCP stand for?\n- `3:19` - How does MCP work?\n- `4:21` - A demo using Claude\n- `7:46` - How I use MCP\n- `14:16` - 3 Parts of MCP\n- `15:14` - stdio vs http\n- `16:31` - Features\n- `17:56` - Resources\n- `18:19` - Prompts\n- `19:19` - Tools\n- `21:12` - Calling Tools\n- `23:03` - MCP vs AI features\n- `28:29` - Building an MCP Server\n\n## What is MCP\n\nMCP is just a standard way to plug tools in to an AI.\n\nOut of the box a model can only talk. It can tell you all about your email or your database, but it has no way to actually send the email or run the query. **Model context protocol** closes that gap: you run a small server that exposes tools, your AI connects to it, and now it can go do things in your apps instead of just chatting with you about them.\n\nAnthropic designed it (the company behind Claude), but it's a standard now, not a Claude-only thing. If you're on OpenAI or Gemini or some other tool you're going to run in to the same idea, sometimes under a more general name like connectors or integrations.\n\nThere are two sides to this, and which one you are changes why you'd care:\n\n- If you're a USER of AI, MCP is how you wire your different apps and services in to your AI so it can work across all of them.\n- If you're a DEVELOPER building something, you'll probably end up creating the MCP server for your app, so your users can connect to it through their own LLMs and get abilities specific to whatever your app does.\n\nWe'll touch both. The plan for this one: a quick definition and a demo so you can see what it actually looks like, then back to the chalkboard for the concepts you need, then we build our own server to wrap it up. You don't really need any prerequisites, though if you've seen my API videos the idea is very similar, just adjusted to be more AI friendly.\n\nThe spec is open and genuinely readable if you want the source of truth: [https://modelcontextprotocol.io/docs/getting-started/intro](https://modelcontextprotocol.io/docs/getting-started/intro)\n\n## Course Catalyst Demo\n\nBefore any theory, let's just watch it work.\n\nCourse Catalyst is my own course platform, and it exposes an MCP server. In Claude you go to connectors, add a custom connector, and paste the MCP URL. That kicks you to an approval page, you hit approve, and it's connected. From the connector you can manage it and see the tools it gives you, and they're split in to read-only tools and writing tools: listing page blocks, broadcasts, contacts, coupons, courses, forms, lessons, offers. Pretty much anything you'd do inside the app itself you can now do through the MCP.\n\nFirst something small, I just ask about my platform and it pulls the answer straight from the connection (in my case info about a free Claude Code crash course, day two). No leaving the chat.\n\nThen something with more moving parts. Here's the actual prompt I ran:\n\n> Create a coupon for 30% off the current list price of Agentic AI tier 2 for loyal customers, which would be anyone inside of Software Engineering Mastery. Draft a thank you email to anyone in this bundle, excluding anyone who has already bought Agentic AI. Send me the preview and confirm the recipient count. Coupon expiration is end of day tomorrow. Specify that it's limited time and the subject of the email. Once I approve, we can send it.\n\nOne prompt, and it's creating a coupon, building an audience with an exclusion, drafting the email, and sending me a preview with the recipient count before anything goes out. I switch it to auto mode so it stops asking permission on each step (if you want to know more about auto mode or bypassing permissions, that's in my one hour Claude Code intro). It hands back the preview, I approve, and it's sent.\n\nHere's another one:\n\n> Generate an example landing page with the Agentic AI course tier 2, with the course content block for tier one and two. Default vibe is fine to get something started. Use my synced bio and testimonial blocks.\n\nThe processing can take a bit depending on the ask and the model, so I run it in the background and come back. About 5 minutes with Fable 5, and there's a link to the page. First iteration and it's already got an overview of what the course covers, the actual course structure, the tiers with enrollment options and buy buttons, testimonials, an about me, a Q&A, and another buy button at the bottom. Obviously I'd go through and review and update it, but that saves so much time.\n\nThat's the point of MCP: once your apps expose tools, the AI can go operate them instead of just talking to you about them. Now let's understand what actually happened.\n\n## Migrating My Business\n\nQuick story so you know this isn't a toy demo I built for YouTube.\n\nFor the last 6 months or so I've been building my own platform to host everything for my business. It's multi-tenant, so multiple customers run from the same platform, each with their own landing pages, domains, and customers, all separated out. When I talk about MCP here, one customer connects to just their own environment, a lot like getting an API key scoped to your data on some platform.\n\nThe thing I wanted MCP for first was imports. You can always write scripts to move data around through APIs, and I started down that path, some of those in-app import tools still exist. But what I actually wanted was a full migration across multiple platforms, multiple years of data, thousands of transactions, tens of thousands of contacts, and every course people had bought so they don't lose access. That's a big one, and it's one of the biggest reasons people get stuck on a platform, moving off is just hard.\n\nSo I tried building it through skills and LLMs using MCP. Because it was a bigger effort, I had the LLM keep all its progress in a markdown file, I just call that the vault, and one of the files in there was the migration report, the progress checker. Then I had it scan the other services, Notion, Kit, Kajabi, giving it access either through their MCP or API or just handing it my login token to go grab everything.\n\nThe first thing I'd have it do was write out what needed done, not actually do it, just spec out the work with checkboxes, one box per lesson or video that needed migrated. Then a second box for a separate verifying agent, a fresh context window with no influence from the previous work, just there to catch errors. LLMs aren't flawless so I'd still do a thorough look myself, but you'd be surprised how well it holds up when the work is tracked and each piece is easily verified. Especially with scripts in the mix, so instead of going 100% LLM, it's the LLM plus scripts the LLM writes.\n\nThrough that we imported hundreds of videos and hundreds of thousands of words of notes (videos re-uploaded to the new platform, not just linked), scraped and re-uploaded images from the landing pages and notes, formatted all the code properly in markdown so it renders in the notes, and imported transactions and contacts. I also had it keep a separate section for any conflicts or issues and prompt me for how I wanted them resolved. Quick example, one platform had a course called AI Mastery and I'd renamed it to AI Engineering on the new one, there's no clean one to one match there, so it would just list the conflicts and let me pick the resolution. That mattered for things like old transactions where the product had been archived, what do we even grant those people. The scripts I did my best to make idempotent and I leaned heavily on transactions when appropriate, so a contact import was pass or fail for integrity instead of half applying.\n\nAll of it went in to a skill. Skills are kind of the functions or libraries of the LLM world now, they document and contain the scripts, instructions, and the verifying agent definition, so any time I need to import again I just run the skill.\n\nThat's not really the point of this video, but it's a good example of how far MCP goes for big messy automations where a clean hand-written script isn't quite enough. Ok, now let's learn how the machine actually works.\n\n## Server, Client, Host\n\nThere are three parts to MCP, and people mix the terms up constantly, so let's go through them.\n\nThe **server** is the thing exposing tools, sitting in front of your data or your API. Notion runs one, GitHub runs one, Course Catalyst runs one, and later you'll run your own.\n\nThe **host** is the actual AI application, the thing powering the LLM and running the show, Claude, ChatGPT, Cursor, whatever.\n\nThe **client** is an individual connection from the host to one server. The difference between client and host is a little gray, but that's how I see it, the host is the app, the client is one connection inside it. And one host can hold many clients, which is how a single chat reaches Notion and GitHub and your own app all at once (that's also how the migration worked).\n\nA nice property of it being a standard is the server has no idea which AI is on the other end and doesn't care. Before MCP every app built one-off integrations per AI platform, now you build one server and every MCP-speaking app can use it.\n\nOne more thing about the server: where it lives is irrelevant. Most people picture some external service out there, their email or whatever, but it can just as easily be local tools on your own computer. That gives you two main ways the client and server talk:\n\n- **stdio**, for local apps running in your own environment, communicating over standard in and standard out\n- **HTTP**, for talking over the web\n\nWe'll use stdio for our build since it's just us on one machine, and I'll point at HTTP as the next step.\n\n## The Spec\n\nSince I keep saying \"it's a standard\", it's worth knowing there's an actual spec behind it. It's a versioned document that covers the message format (it's JSON-RPC, more on that in a second), the lifecycle of a connection, and all the capabilities the server and client can negotiate.\n\nDo you need to read it to build something? Not really. If you understand the pieces above you're going to get pretty far, and you can read in to the spec once you get in to the more advanced stuff or when something breaks between a client and server. It's a good read though, shorter than most API docs: [https://modelcontextprotocol.io/specification](https://modelcontextprotocol.io/specification)\n\n## Resources, Prompts, and Tools\n\nGoing a bit more in to the spec, there are three things the server can provide to the client: resources, prompts, and tools. This is basically everything the server hands over to teach the LLM how to use the service, and I'm going to spend almost all of our time on tools, because I think that gets you 90% of the way there, possibly all you'll ever need.\n\nTechnically the client can give the server some stuff back too. The three I've memorized are sampling, roots, and elicitation. For my own MCP I've never had to touch any of them, everything I do is wrapped through tools, so you can build a fully working server and only worry about that one piece. Do your own research on the client side if you get curious, we might do a dedicated video on it down the road.\n\nQuick pass on the other two first.\n\n**Resources** are a way to read data from the server. If you've got an API background you've heard \"resource\" used for an entity, the actual thing you're getting from a database, and it's the same flavor here, read-only data addressed so the client can pull it in. In practice you can just make read-only get tools instead, so I don't lean on resources much.\n\n**Prompts** are pre-canned messages the server hands to the client to guide it, so instead of just handing over a pile of tools you can also give the client prompts on how to work with your server. It's really similar to a skill or a slash command, a prepackaged message that brings context in to the thread. The only real difference is where it lives and how much it carries, a skill usually has more data and larger workflows, but in theory a skill and a server prompt can be the exact same thing.\n\n## A Tool Call on the Wire\n\nNow tools. You can think of these as endpoints the client invokes on the server.\n\nThe messaging is JSON-RPC. RPC stands for remote procedure call, and it's very close in idea to invoking an endpoint on a server with an API. A request has a `jsonrpc` version, an `id`, and a `method`. The first call just lists what's available:\n\n```json\n{ \"jsonrpc\": \"2.0\", \"id\": 1, \"method\": \"tools/list\" }\n```\n\nThat gives the AI a high level view of what tools it could use, stuff like `get_coupon`, and very often each one goes one to one with an API endpoint. If you look at any particular tool you'll find a `description` attribute. Think of it like a comment, except it's written specifically to tell the LLM invoking it how to use it and what to expect. So instead of writing comments for other developers, we're writing comments for LLMs so they use the tool correctly and don't screw things up. The description is the context we're infusing in to the client, that's what I want you to see it as.\n\nThen the client makes another call, but the method is `tools/call` instead of `tools/list`:\n\n```json\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 2,\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"create_coupon\",\n \"arguments\": { \"code\": \"YOUTUBE20\", \"percentOff\": 20 }\n }\n}\n```\n\nNotice `params` does double duty. The `name` says which tool we're actually calling, and `arguments` is the payload the server defined for that tool. Then, just like with an API, the server responds with something the consuming LLM might need for later work, the created coupon's id, a confirmation, whatever. That's where we'd confirm the coupon was actually made.\n\nWe could talk theory forever, but let's wrap the chalkboard with one more thing before we build.\n\n## MCP vs AI Features\n\nSometimes a thing could live in either an MCP or a built-in AI feature, and you have to pick, so here's how I think about it.\n\nIf you're building an app you could put an AI button right on the page, click it and the user generates something, reviews something, does some AI stuff. That hits your server, works with your data, and costs YOU tokens, but it's a nice native experience, the user doesn't have to connect to Claude or anything, they just click.\n\nBut those buttons are often an alternative to an API. If the button creates a page by adding blocks, an API could add those same blocks, and anything you can do through an API you can do through MCP. So you could skip the built-in button and just expose the same tools over MCP. In that version the user runs it from their own LLM, so THEY pay the tokens, and your server basically acts like an API, no AI compute on your side. That means no worrying about credits or people abusing your AI features, it's all delegated to the user.\n\nThe downside is they have to connect their LLM to your service, and you know how users are, an extra step they don't understand is a step a lot of them just won't take. A built-in button is less scary, they're already logged in.\n\nSo you have to think about what belongs in the MCP. My take: if you have enough tools to fully operate the app through AI, push people toward the MCP and go lighter on the built-in AI features, because at that point AI is the interface. But if you just want one AI thing, like summarizing some notes, making them connect an MCP and invoke a tool for that is not the way, just build the feature. I'd only really invest in the MCP layer if you're building a whole new way of working with the app.\n\nRealistically you'll see apps do both, AI-enhanced features and search and summaries built in, plus an MCP for the action stuff, creating, updating, connecting, analyzing. Right now it's kind of the wild west, there's some standardization but one platform's MCP can take a totally different approach than another's. Over time I think that settles down, to where working with an MCP is predictable because everyone's used to running apps through their LLM. Ok, enough chalkboard, let's build one.\n\n## Build Step 1 - The API\n\nWe're going to build a tiny API first, then wrap it with an MCP server, so you can see exactly where the MCP layer sits.\n\nFresh folder, a node project, and the packages:\n\n```bash\nmkdir mcp-example\ncd mcp-example\nnpm init -y\nnpm install @modelcontextprotocol/sdk\nnpm install -D typescript tsx\nnpm install express\n```\n\nI like starting with TypeScript even when I'm not sure I'll use much of it. Make a `server.ts`, and this is just a normal little Express API with the coupons kept in memory:\n\n```typescript\nimport express from \"express\";\n\nconst app = express();\n\nconst coupons = [\n { id: 1, code: \"YouTube20\", percentOff: 20 },\n { id: 2, code: \"launch\", percentOff: 10 },\n];\n\napp.get(\"/\", (req, res) => {\n res.json({ coupons });\n});\n\napp.listen(3000, () => {\n console.log(\"Running on http://localhost:3000\");\n});\n```\n\nTry to run it with `node server.ts` and you'll get an error:\n\n```\nSyntaxError: Cannot use import statement outside a module\n```\n\nNode's telling you to treat these files as ES modules, so pop open `package.json` and set the type (mine was `commonjs`, switch it):\n\n```json\n\"type\": \"module\"\n```\n\nRun it again, open `localhost:3000`, and there's the JSON. That's basically a mocked API, in a real app that data comes from a database. Point is we now have an app server.\n\n## Build Step 2 - The MCP Server\n\nNew file, `mcp-server.ts`. This is where we do the same stuff as the API, but through the MCP layer. Start with the imports:\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol/sdk/server/mcp\";\nimport { StdioServerTransport } from \"@modelcontextprotocol/sdk/server/stdio\";\n```\n\n`StdioServerTransport` is the local transport from the chalkboard, it communicates over standard in and standard out, so you can kind of think of anything we'd normally console log as what's getting sent. Now the server itself, and the connect line at the very end:\n\n```typescript\nconst server = new McpServer({ name: \"product-server\", version: \"1.0.0\" });\n\n// tools go here\n\nawait server.connect(new StdioServerTransport());\n```\n\nIt's a bit of setup to get going, but you only do it once. After that, adding a tool is the same shape every time. Here's our first one:\n\n```typescript\nserver.registerTool(\n \"list_coupons\",\n {\n description: \"Lists out available coupons and % discount\",\n },\n async () => {\n return {\n content: [{ type: \"text\", text: JSON.stringify(getCoupons()) }],\n };\n }\n);\n```\n\nThe name is `list_coupons`, then a settings object where the description is the message that goes to the LLM. There's also an optional input and output schema you can define here, we'll skip that for a plain get. Then the function that actually runs, returning an object with `content`, which is an array of items that each have a `type` and a `text`.\n\nFor the text I'm calling a `getCoupons()` function instead of touching the array directly. Since the API and the MCP server are running in the same place, I don't need to make an HTTP call, I can just share the code. Over in `server.ts`:\n\n```typescript\nexport const getCoupons = () => {\n // any logic here\n return coupons;\n};\n```\n\nAnd the endpoint can return `getCoupons()` too. So right now the tool is literally a one to one with the API endpoint, doing the exact same thing.\n\n## Build Step 3 - Splitting Out the Shared Code\n\nIf you import `getCoupons` straight from `server.ts` you drag the whole Express app along with it, `app.listen` is a top level line, so importing the file starts the server. That was a mistake in how I structured it. The fix is to pull the shared stuff in to its own file so neither side has to run Express.\n\nMake `coupons.ts` and move the data and the functions there:\n\n```typescript\nconst coupons = [\n { id: 1, code: \"YouTube20\", percentOff: 20 },\n { id: 2, code: \"launch\", percentOff: 10 },\n];\n\nexport const getCoupons = () => {\n // any logic here\n return coupons;\n};\n```\n\nNow `server.ts` imports `getCoupons` from `./coupons`, and `mcp-server.ts` imports it from `./coupons` too, and the MCP server runs on its own without the API server running at all.\n\nBefore this compiles cleanly, generate a tsconfig and give it a few settings:\n\n```bash\nnpx tsc --init\n```\n\n```json\n{\n \"compilerOptions\": {\n \"target\": \"ES2022\",\n \"module\": \"NodeNext\",\n \"moduleResolution\": \"NodeNext\",\n \"esModuleInterop\": true,\n \"skipLibCheck\": true,\n \"strict\": true\n }\n}\n```\n\nThen compile and run:\n\n```bash\ntsc\nnode mcp-server.js\n```\n\n## Build Step 4 - Connecting It to Claude Code\n\nWe understand the server from the consuming end, now let's actually connect to it. This time we'll do it through Claude Code. From inside the folder:\n\n```bash\nclaude mcp add coupon-server -- node /Users/codebreakthrough/cs/mcp-example/mcp-server.ts\n```\n\nUse the absolute path to your file (right click, copy path). That command is just how Claude launches your server as a local process, the stdio transport again. Launch `claude`, trust the folder, and run `/mcp`, and it lists your connections. The very first section is local MCPs, so go in to the coupon server and you can disable, reconnect, or view tools, where you'll see that description we wrote.\n\nNow a prompt. Even when you don't have to name the server it's sometimes smart to, so it doesn't grab the wrong thing when you've got multiple connections that could have coupons:\n\n```\nuse local stdio MCP server to get all coupons and show which is the best\n```\n\nIt calls `coupon-server`, comes back with the two coupons, YouTube20 and launch10, and picks YouTube20 as the best, your own server getting called by the AI.\n\n## Build Step 5 - A Write Tool\n\nThe get is nice, let's add one that changes data. Back in `coupons.ts`:\n\n```typescript\nexport const createCoupon = (code: string, percentOff: number) => {\n const coupon = { id: coupons.length + 1, code, percentOff };\n coupons.push(coupon);\n return coupon;\n};\n```\n\nThen register a matching tool in `mcp-server.ts`:\n\n```typescript\nserver.registerTool(\n \"create_coupon\",\n {\n description: \"creates a coupon\",\n },\n async ({ code, percentOff }) => {\n const coupon = createCoupon(code, percentOff);\n return {\n content: [{ type: \"text\", text: JSON.stringify(coupon) }],\n };\n }\n);\n```\n\nThe arguments come in as a single object that we destructure and pass through to `createCoupon`. That gives us a schema-expectation problem though, we never told the tool what shape those arguments are. That's what the input schema is for, and we'll define it with zod:\n\n```typescript\nimport { z } from \"zod\";\n```\n\n```typescript\nserver.registerTool(\n \"create_coupon\",\n {\n description: \"creates a coupon\",\n inputSchema: {\n code: z.string(),\n percentOff: z.number().min(1).max(100),\n },\n },\n async ({ code, percentOff }) => {\n const coupon = createCoupon(code, percentOff);\n return {\n content: [{ type: \"text\", text: JSON.stringify(coupon) }],\n };\n }\n);\n```\n\nNow it knows `code` is a string and `percentOff` is a number between 1 and 100. Compile again (always recompile to get the latest JavaScript if you're on TypeScript), and back in Claude you might see a failed connection if the old server shut down, so just reconnect. Then:\n\n```\ncreate a new coupon code for 60% off\n```\n\nIt calls the server, creates it, and hands back Save60.\n\n## Where to Go Next\n\nThat's your introduction. There's obviously so much more you could do.\n\nFirst thing I'd do is get rid of the in-memory array, that's going to bite you the moment you're running through both the API and the MCP, so move it to a database, then build out more endpoints and more tools to work with that data. At some point you'll want to break away from stdio and look in to HTTP so other people (or your phone) can reach the server, and the process is pretty similar. Maybe we'll get in to that in an upcoming episode.\n\nThe fastest way to make all of this stick is to wrap something you already own. Pick an API you use, expose a couple tools, and go ask your AI to do something with it.",[],[],"5f41128e-7540-4c81-ab23-626f5cea5387",2688,"connect-ai-to-anything-build-your-first-mcp-server-model-context-protocol","Should You Still Learn to Code?",6,820,"should-you-still-learn-to-code","3 Things I'd Learn in the Age of AI",5,"3-things-i-d-learn-in-the-age-of-ai","20 minutes is all it takes to learn AI",4,"## Timestamps\n\n- `00:00` - intro\n- `00:46` - ChatGPT or Claude?\n- `02:07` - Setting up your model using memory\n- `04:04` - Skills\n- `04:52` - How to create your own skills\n- `07:28` - An example using skills\n- `12:06` - Other tools\n- `12:38` - Claude Cowork\n- `17:14` - Getting started with Claude Code\n- `20:12` - What's next?\n\nThere are a lot of different players when it comes to AI. ChatGPT is a big one, Claude is another, there's Grok and a bunch of others you're going to hear about. Which one you choose probably doesn't make all that much of a difference.\n\nI use Claude for the majority of my work, so that's what everything here is built around. Claude currently does not have a free version though, so if you want to follow along without signing up or paying for anything, try ChatGPT instead. You can also download local models if you want to go that route, but most people who want to start using AI don't start there.\n\nWhatever you pick, download the desktop app instead of living in the browser. Search for it, download, run it. It looks pretty much the same as the website, but running it as an app on your computer is an overall better experience. [https://claude.ai/download](https://claude.ai/download)\n\n## Projects\n\nMost people start in the default chat window. I'm not going to recommend that.\n\nCreate a **project** instead. A project is where you define what you're working on, and every chat you start inside it gets organized under it. You can pin the project and it shows up in the pinned section on the side.\n\nThe magic is further down the page. Scroll and you'll find instructions, memory, and context. A default chat window knows nothing about you or what you're trying to accomplish, so you restart from zero every single time you open it. In a project, you write the instructions once: what you're doing, what you want to accomplish, how you want the chat to act.\n\nContext is any document it might need to reference. Say you're working on something for work and it has to stick to a product spec or some terms of service, you drop that in the project context and it's available in every conversation there. Spreadsheets, documents, photos, same deal. If it's a one-off file you don't need everywhere, just attach it to the single chat instead.\n\nThe project doesn't have to be work either. Budgeting, some weight loss goal, organization, whatever you're actually trying to get done.\n\nConnectors live behind the plus button in the chat. I have one hooked up to Course Catalyst, which is the platform I built, and that's how you get the AI interacting with other services.\n\n## Skills\n\nA skill is how you organize a task you're going to do repetitively. It's basically just a way to copy and paste some instructions whenever you need them.\n\nThere's a browse screen with a bunch of available skills, mostly from Anthropic, who make Claude. A web artifacts builder if you want it generating HTML pages, a morning brief, that kind of thing. You can find skills online and install those too.\n\nWhat I like to do is create my own, and the easiest way is to just ask for one. There's a skill creator skill, but you don't really need it.\n\n### A dumb first skill\n\nI told it:\n\n```\nWhenever I say hello and invoke the skill, say the date and hello Caleb.\n```\n\nThat's it as far as setup goes. It writes the skill as a markdown file, which is just a way to structure text, describing what it's supposed to do and the format it's supposed to be in. Save it, then type `/hello` in a chat and it loads the skill and gives back the date and hello Caleb.\n\nTotally useless, and that's the point. The example is there to show you how it wires up, then you build on it.\n\n### One that's actually useful\n\nSecond one, still simple. I wanted to hand the AI a pile of information and have it split that out in to a to-do list, notes to keep track of, and blockers I'm waiting on.\n\nI'm organizationally incompetent, effectively, so having AI do that part for me is a big deal. The prompt I gave it was to repeat back a brain dump from me, split in to to-dos, things to remember, and blockers, and to update the list on later messages telling me what changed.\n\nThen I dictated a mess at it: I need to clean my house but I can't because I'm waiting on cleaning supplies, I spent $712 on cleaning fees last month and I want to track whether that improves, and I need to pick up a plunger and some pizza. It came back with the to-dos, the note about the $712, and the blocker on the cleaning supplies.\n\n> [!tip]\n> Sometimes Claude picks up on the skill and just runs it, but I usually prefer to be explicit and invoke it by name, so I type `/organize` myself.\n\nNow, the thing you should know is that this does not persist between conversations. Unless Claude decides to write something to its memory, it lives in that one chat. So the next logical step is storing that information somewhere, a file, a database, Notion, something like that, and you can get AI to build that part too. If you're not sure what to do next, ask it, \"how could we persist this between sessions?\" You don't have to know the answer ahead of time.\n\nSkills are one of the biggest unlocks with AI, and also one of the simplest things in Claude. Pretty much any capability you want, you can describe inside a skill, and you can publish it and share it with other people. So when you see someone online talking about how they got Claude to do X, there's a very good chance it's just a skill with instructions telling the LLM how to do that thing. Someone took the time to write down how to design a web page, or they had Claude help them write it down, and now it's a design skill.\n\n## Cowork\n\nThere's a middle ground between the basic chat and Claude Code, and it's worth knowing about even though I don't personally use it much.\n\nInside a project I asked it to create a file that can persist across sessions, then started a new chat in that project using cowork and said \"read project state and make an example edit to it\". The file is `project-state.md`, sitting in a folder, and the new chat read it and changed it. So you can work on something over time across different chat windows.\n\nThat's the actual benefit of Claude Code too, working on your own files so the stuff persists. Checklists, SOPs, configurations you update as you go. Instead of one-shotting a chat and hoping you get the right result, which is what a lot of people do with AI and why they don't get great results, you keep improving the same thing.\n\nThe next step from there is scheduling. The example it suggests is a daily briefing, and I think that's a strong starting point, because it isn't doing anything on your behalf, it's just reading and telling you what's going on. Emails you need to reply to right away, leads on social you forgot to reach out to, GitHub issues worth reviewing. You can run it manually or on a recurring basis.\n\nI don't have a daily briefing set up right now. I have something in the works, but it's not where I want it to be yet, so that's probably future content.\n\n## Claude Code\n\nThis is the next step in the progression, and I already have a dedicated video on it that runs about an hour, so I'll point you there for the details: [One Hour of Claude Code](https://youtu.be/8PVGtt7Fa7g). This video here is the precursor to that one.\n\nTo get started, the installation command is in the docs at [https://docs.claude.com/en/docs/claude-code/overview](https://docs.claude.com/en/docs/claude-code/overview). I'm not actually sure whether it comes installed with the desktop GUI, it might, so you could just try it first.\n\nI like to run it from a folder:\n\n```bash\nmkdir my-project\ncd my-project\nclaude\n```\n\nIf it's installed, it works. If not, run the install command from the docs.\n\nInside, you can toggle between modes, and eventually you'll graduate to auto mode so you're not approving every permission (I cover setting that up in the other video). Everything it generates goes in the folder you launched from.\n\nYou don't need a software development background for this, and you don't have to use it for coding. It can generate websites, apps, markdown files, CSV, Excel. It talks to other apps, APIs, and MCP servers, and works with pretty much every file type. You'll get a lot more done this way.\n\nQuick example: my thumbnail. Not the most amazing thumbnail you've ever seen, but it wasn't \"hey, generate me a thumbnail\" either. The styling and the positioning of all that data are anchored in HTML, so I don't just have a PNG sitting there, I have the file that produced it and I can open it in VS Code and change any of it. That's way better than going to ChatGPT and asking for an image. I'm just using Claude Code to code, it just happens that what it's coding is an image.\n\nThere's also a remote control option, which puts the session in the code tab in the Claude app on your phone. That's what I do when I have something bigger, fire off a task that might take an hour or two and check in from my phone while I go to the store or go have a life outside of sitting at the computer. I say that, but I usually just sit at the computer.\n\n## What's next\n\nStart using AI every day and figure out what it can do for you. Build out workflows for the things you already do, and go research what other people are doing with it. I follow a bunch of people on social media and I'm constantly getting videos of \"here's how I used Claude Code to do this\", and that gives me ideas to pull back in to my own workflows.\n\nLearning the actual tools and the infrastructure goes a long ways, so you're not stuck in basic prompting. I'll have subagents working for multiple hours on different features. More on all of that in the [hour-long Claude Code video](https://youtu.be/8PVGtt7Fa7g).",[],[],"d176ce1c-a7e9-487b-b5b7-a7d45efe87a2",1300,"20-minutes-is-all-it-takes-to-learn-ai","This will change the way you build websites (3D Sites with Claude Code + Higgsfield)",677,"this-will-change-the-way-you-build-websites-3d-sites-with-claude-code-higgsfield","The best way to build mobile apps in 2026","## Timestamps\n\n- `00:00` - Intro\n- `04:01` - Which Stack to Choose\n- `07:41` - How I Built My App\n- `08:26` - Keep V1 Thin\n- `09:55` - Example Spec\n- `12:02` - Subagents\n- `13:55` - Auditing Your App\n- `15:45` - Plugins and Skills\n\nI'm building a mobile app for Course Catalyst, and agents wrote most of it. The trick was anchoring it against the web app that already exists, so the AI could look at how the backend and the browser version work and translate that to mobile.\n\nThe app itself is a learning platform. You can watch lessons from me and other instructors, each lesson has notes, a library keeps track of what you're working through, and a marketplace aggregates courses from every instructor on Course Catalyst with a product in the marketplace. V1 is pretty simple, and that's on purpose.\n\n> [!tip]\n> This video was sponsored by GoLogin. I don't own any Android phones, so I test on [Cloud Android](https://bit.ly/gologin_caleb-curry), virtual Android devices you run from the browser, with different configurations and proxies for testing from other regions. There's also an official GoLogin MCP server if you want Claude Code driving the device. Promo code `CALEBCURRY40`.\n\n## Which Stack to Choose\n\nThere are about five realistic options, and the right one comes down to what infrastructure you already have and what devices you want to deploy to:\n\n- Swift - native iPhone\n- Kotlin - native Android\n- [Kotlin Multiplatform](https://kotlinlang.org/multiplatform/) - cross-platform. Promising if you're starting from scratch, though I haven't tried it myself\n- [Flutter](https://flutter.dev) - popular cross-platform option\n- [Expo](https://expo.dev) (React Native) - cross-platform, builds off React\n\nAll of these compile natively, and that matters. Sometimes you'll see an \"app\" that's really just a web page viewed through the phone, that's not what you want for a new app.\n\nGoing native with Swift or Kotlin makes sense if you're only ever going to be on one platform, or if you need some very specific capability you can't get cross-platform. If you don't know what those specific capabilities are, it's probably not an issue for you, so I wouldn't worry about it. Even then, you can still write small bits of Swift or Kotlin specific code from a cross-platform app, so it's not necessarily a dealbreaker.\n\nIt's worth noting that going native doesn't mean the whole system is written in that language. Keep the app layer thin and put most of the logic in a centralized backend that the iPhone app, the Android app, and the web app all call.\n\n## How I Built My App\n\nThat thin app layer is the architecture I went for. My backend and my web frontend are both JavaScript, and as a single developer I wanted as little language switching as possible, so React Native gave me the most bang for my buck. One JavaScript backend, three frontends (web, iPhone, Android), and the mobile apps still compile natively to the devices.\n\nEven things you don't think about upfront get shared, like types. I don't have to define a course object or a lesson object in three different languages and do data conversions between them.\n\nMost of the capabilities I needed already existed in the backend and the web app, so the mobile version was not a huge lift. I spent a lot of time writing a spec, then had the LLM implement it by looking at the existing backend and how interactions work on the web app. It wasn't snap-my-fingers done, there was still back and forth, but way simpler than maintaining Swift plus Kotlin plus my JavaScript web stack.\n\n## Keep V1 Thin\n\nThere were a ton of features I wanted in V1, and I removed most of them. Not just for technical complexity, but for compliance and app store approval. The fewer features you have, the easier it is to get through that door, and you can keep adding things after.\n\nTwo things I deferred:\n\n- Payment processing. My marketplace only has free products for now. In-app payments bring app fees and extra scrutiny, and my app is really a gateway that can lead to purchases on the desktop later\n- Admin controls. No course editing, no seeing students in your course. It's a student-facing app in V1, less features means less bugs and an easier approval\n\n## Example Spec\n\nSaying \"write a spec\" can feel a bit vague, so here's what mine looks like. I don't write it from scratch, I describe the features and have the AI build the spec out: what students need (search, the marketplace, and so on), plus a separate file for V2 ideas so they don't get lost or interrupt what we're currently working on.\n\nThere's also a running list of decisions made along the way. A few from mine: the app is pure client with no mobile backend, React Query for the data layer, and types generated from the OpenAPI spec off my backend. Most of these details I don't need to memorize, the AI uses them to keep its understanding of the app up to date.\n\nOne important thing: any spec that's a living document describing how the app currently works needs updated as the code changes. Put that instruction at the top of your CLAUDE.md (or whatever your agent reads) so the specs don't drift from the actual code.\n\n## Subagents\n\nThe spec is really there so I can delegate. Do the research and spec writing with a higher cost model, then hand implementation to a cheaper model, and confirm the work with tests and by checking it against the spec. Done properly, you can build very large portions of your app without running out of credits or sitting there answering questions as they pop up.\n\nThings still come up mid-run, so I triage decisions by how reversible they are. If a choice is easy to reverse, the agent just makes it. If it's a little risky, take a note of it. If it's genuinely hard to undo (a framework choice, for example), don't implement it, stop and get an answer from me. With that in place the agents run for quite a long time, implement pretty much the entire spec, and then I go test things myself.\n\n## Auditing Your App\n\nThe hard part for me wasn't really the building, it was getting the app in to the stores in good standing. I had agents do deep research on the [Apple review guidelines](https://developer.apple.com/app-store/review/guidelines/) and the Play Store requirements, and extract only what's relevant to my app in to a concise checklist. Then, once the app is almost ready, an agent audits the app against that list.\n\nOne example from mine: account deletion. Deleting an account has to actually remove it from your records along with the associated data (anything you're not legally required to keep). A soft delete flag that keeps the account row and its email fails this. Google also lets you offer deleting some data without deleting the whole account, but that's an additional option, not a replacement. Then there's a bunch more on privacy policies and packaging, the app icon, the description, all of that.\n\n## Plugins and Skills\n\nI built my auditing checklist myself with AI help, but before you do that for everything, search for what already exists in your ecosystem. Expo publishes a set of [skills](https://github.com/expo/skills) you can pull in locally so your agent already knows how to do a bunch of things, like bringing an existing React web app to iOS and Android, and there's even a store submission workflow for releasing through EAS. Your agent being informed up front beats it doing research or trying outdated methods mid-build.\n\nMy app is most of the way there, not 100%, but I hope to have it out very soon, and there will be some course content on it you can view for free.",[],[],"c9dab8ed-004e-4be5-8bb0-916946ca8ef1",1081,"the-best-way-to-build-mobile-apps-in-2026","Autonomous AI and Agent Orchestration - Buzz + Paperclip","## Timestamps\n\n- `00:00` - Intro\n- `01:30` - VPS Setup\n- `03:29` - App Overviews\n- `08:01` - Cost Management\n- `09:33` - What are heartbeats in Paperclip?\n- `10:18` - Assigning a task in Paperclip\n- `10:43` - Setting up our Paperclip structure\n- `12:11` - Building out a Workflow\n- `12:38` - What was created in GitHub?\n- `13:41` - SSH Port Forwarding\n- `14:23` - Typeform\n- `19:00` - Creating agents with Buzz\n- `23:44` - An overview of everything Buzz can do\n- `24:26` - Running local models through Buzz\n- `26:25` - Building with Buzz\n- `29:40` - Buzz vs Paperclip\n\n[Buzz](https://www.hostg.xyz/SHJy7) and [Paperclip](https://www.hostg.xyz/SHK2H) both help manage AI agents, but they go about it in pretty different ways.\n\nBuzz is a shared workspace. You talk to agents in channels and DMs, kinda like Slack. Paperclip is organized around a company, an org chart, tasks, budgets, and scheduled runs called heartbeats.\n\nThe initial difference is who starts and assigns the work. In Buzz, you normally mention an agent and tell it what to do. Other people on your team can join the workspace and use the agents you allow them to access. In Paperclip, work usually moves down from the company goal through the CEO and other managers, then agents wake up on heartbeats to check what is assigned to them.\n\n## VPS setup\n\nBoth projects can run locally. I put them on a VPS so they can stay available and respond to events even when my computer is off.\n\nHostinger has one-click installs for both:\n\n- [Deploy Buzz on Hostinger](https://www.hostg.xyz/SHJy7)\n- [Deploy Paperclip on Hostinger](https://www.hostg.xyz/SHK2H)\n\nUse code `calebcurry` for an extra 10% off. I used the KVM 2 plan and installed both apps on the same VPS.\n\nBuzz also needs its [desktop app](https://buzz.xyz). Choose **Join a community**, copy the public `npub1...` key, then use the relay URL from Hostinger's Docker Manager to connect.\n\n> [!tip]\n> Your `npub1...` value is public. An `nsec1...` value is your private identity key and should not be pasted into a form, chat, or server configuration.\n\nIf you want Claude Code to walk through the Hostinger setup, connect the [Hostinger MCP server](https://www.hostinger.com/support/how-to-use-hostinger-api-mcp-server/):\n\n```bash\nclaude mcp add --transport http --scope user hostinger https://mcp.hostinger.com\nclaude mcp login hostinger\nclaude -c\n```\n\nHere is a shorter version of the setup prompt I used:\n\n```\nYou are my Hostinger deployment copilot. Help me deploy either Buzz or\nPaperclip on a Hostinger VPS. Use the Hostinger MCP tools for anything you\ncan do automatically and give me exact browser steps for everything else.\n\nWork one step at a time. Start by asking which app I want to deploy, then:\n1. List my VPS instances and subscriptions.\n2. Recommend the right VPS and ask before purchasing anything.\n3. Walk me through the one-click install in Docker Manager.\n4. Configure the firewall for SSH, HTTP, HTTPS, and required app ports.\n5. Verify the containers are running and healthy.\n6. Give me the app URL and explain how to connect.\n\nNever purchase, delete, or run a destructive command without showing me\nexactly what will happen and getting my explicit approval. Never ask me to\npaste a password, API key, nsec key, or other secret into chat.\n```\n\n## Paperclip\n\nThe [Paperclip quickstart](https://docs.paperclip.ing/guides/getting-started/five-minute-path/) starts with a company and its goal. The first agent is the CEO, which can propose more hires and pass work down through the org chart.\n\nI started with an existing software product and gave Paperclip this basic context:\n\n```\nThis is a live product for hosting digital products. I need help with bug\nfixes, features, UX, and making it usable for new customers. I am a solo\ndeveloper, the project scope has grown, and it is challenging to keep up.\nSmall feature requests would help get this first push finished.\n```\n\nThe CEO proposed an org structure, then I approved the hires I wanted. You can ask a leader to propose a hire, configure a runtime yourself, or copy an onboarding prompt to an outside agent. My example ended up with a triage lead, product engineer, and UX specialist underneath the CEO.\n\nOpen an agent to see its assigned issues and individual runs. The inbox collects failed runs and approvals, so this is where I found a missing GitHub secret and an agent that stopped after running out of credits.\n\nEach agent has its own configuration, instructions, runtime, and budget. Runs are triggered through **heartbeats**. I would leave scheduled heartbeats off while learning the tool and trigger them manually, especially if the agents are using paid APIs.\n\nPaperclip burned through my starting credits pretty quickly while I was setting up the company. Set company and agent budgets before letting heartbeats run on a timer.\n\n### Using a Claude subscription\n\nIn the recording I tested using my own Claude subscription with Paperclip instead of paying for every request through an API key. I generated the setup token with:\n\n```bash\nclaude setup-token\n```\n\nThe result from `claude setup-token` is a credential, so treat it like a password. In current Paperclip, choose the `claude_local` adapter and use its Claude subscription login flow. Enter the result only when that protected flow asks for it. Don't put it in the agent instructions, source control, or the `ANTHROPIC_API_KEY` field, since that field is for usage-based API keys.\n\nCodex works a little differently. On the same machine that runs Paperclip, sign the Codex CLI in to your ChatGPT subscription with:\n\n```bash\ncodex login --device-auth\n```\n\nComplete the browser flow and leave `OPENAI_API_KEY` unset. Paperclip's `codex_local` adapter can copy the host Codex login in to its managed agent home. You can check the login with `codex login status`. The [official Codex authentication docs](https://developers.openai.com/codex/auth) cover the normal browser flow, device login, and headless machines.\n\nIf you want your local AI agent to walk you through either setup, copy this prompt:\n\n```\nHelp me connect this Paperclip install to my own Claude or ChatGPT\nsubscription.\n\nFirst inspect the current Paperclip version, where it is running, and which\nadapters are installed. Ask me to choose Claude or Codex. Use the current\nofficial Paperclip and provider docs. Do not switch me to API billing unless\nI choose it.\n\nFor Claude, use the claude_local adapter and Paperclip's built-in Claude\nsubscription login. Tell me when to run claude setup-token, then pause while\nI enter the returned credential directly into Paperclip's protected login\nflow. Never ask me to paste the credential into chat, shell history, source\ncode, agent instructions, or a normal environment variable.\n\nFor Codex, use the codex_local adapter. Run codex login --device-auth on the\nsame host as Paperclip, then pause while I complete the official browser\nflow. Leave OPENAI_API_KEY unset so Paperclip uses the host ChatGPT login.\n\nAfter authentication, run the available login status check, use Paperclip's\nTest Environment button, and run one manual heartbeat. Keep scheduled\nheartbeats off. If this Paperclip version does not support subscription auth,\nstop and explain what is missing instead of silently using an API key.\n```\n\nThis is the part I was uncertain about in the video. Anthropic's current guidance says an end user can sign in to an unmodified Claude Code binary with their own subscription, including when a platform hosts it. It also says third-party developers cannot route requests through a user's plan credentials or collect and store Claude session tokens. Read [Claude Code legal and compliance](https://code.claude.com/docs/en/legal-and-compliance) before deciding whether your exact Paperclip setup fits those rules.\n\nAnthropic has also paused its planned subscription credit changes. For now, Claude Agent SDK, `claude -p`, and third-party app usage still draw from the normal subscription limits. Check the [current subscription update](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan), since this policy has already changed during the life of this recording.\n\nPaperclip's [official quickstart](https://docs.paperclip.ing/guides/getting-started/five-minute-path/) uses a provider API key. That is the clearer default if you do not want to depend on subscription behavior. Whichever route you use, set a small budget and keep heartbeats manual while testing.\n\nWhen you are ready to test an agent, assign one small task and run a heartbeat manually. You can assign directly to the worker or give the request to the CEO and let it move down the org chart. The run log shows the model checking the task, doing the work, and reporting the result.\n\nFor GitHub access, create a [fine-grained personal access token](https://github.com/settings/personal-access-tokens/new). Select only the repository the agent needs, use an expiration, and grant the smallest permissions that fit the task. My coding workflow needed repository contents and pull requests. Store the token in Paperclip's secrets area rather than an agent prompt.\n\nPaperclip can also give a local coding agent access to its setup. From the Paperclip container, start the auth flow with:\n\n```bash\npaperclipai auth login --no-browser --api-base http://localhost:3100\n```\n\nOpen the approval URL it prints while signed in to Paperclip. Keep the returned token out of chat and source control.\n\nTo inspect an app running on the VPS, use SSH port forwarding. Replace both ports and the server address with the values from your setup:\n\n```bash\nssh -L LOCAL_PORT:localhost:REMOTE_PORT root@YOUR_VPS_IP\n```\n\nThe example in the video had Paperclip import GitHub issues, propose an implementation, build a Typeform webhook integration, and open a pull request. Its test plan posted a realistic webhook payload, posted it again to confirm deduplication, then sent the wrong secret and expected a `401`.\n\nI connected the real [Typeform](https://www.typeform.com/) webhook and submitted a form with a name, email, referral source, and monthly revenue. The first result reached Course Catalyst, but the nested Typeform fields were not parsed correctly because the agent had assumed a payload shape without checking it. I sent the failure back, and the next change stored the correct name, email, and custom attributes.\n\nFor future tasks I would require the agent to name the source it used for any external payload or data structure. That makes the assumption easier to catch during review.\n\nI would keep a human check before merge. The useful part for me is getting a branch, test URL, and reviewed pull request instead of starting each issue from an empty editor.\n\n## Buzz\n\nBuzz agents run through [ACP](https://agentclientprotocol.com/), which lets the workspace connect to harnesses such as Codex or Claude. The execution can stay on your local machine even when the Buzz relay is hosted on the VPS. That also means the agent can use MCP connections already configured in its local harness.\n\nI used Buzz for task updates, daily research, watchers for new content, and visibility into tools such as GitHub, Notion, and Paperclip. There is also a mobile app, which makes the shared workspace more useful away from the desk.\n\nAn agent is configured around the job first, then you choose the harness and model. My work-prioritization agent used Codex with a cheaper model and read Notion through the MCP connection already configured on my computer. I did not need to copy the Notion connection into Buzz because the agent execution was local and inherited the existing Codex setup.\n\nOther examples in the recording included a daily research agent that looked for AI and backend engineering topics, a watcher for newly published YouTube videos, and channels that pulled updates from GitHub and Paperclip into one place. An agent with the GitHub CLI could then inspect issues from the same channel.\n\nThis was the main instruction for the engineering agent:\n\n```\nYou will be fed a GitHub issue. Build the fix according to the issue as\nclosely as possible. Confirm it does not already have a pull request before\nstarting. Do not commit, merge, or deploy anything. Get the example running\nlocally, then respond with a summary, a URL to test, and clear instructions.\n```\n\nI later added a reviewer agent and had the engineer tag it on each pull request. The reviewer suggested corrections and approved the final change, but neither agent could merge.\n\n## Local models\n\nBuzz can connect to an OpenAI-compatible local endpoint. I used [Llama](https://github.com/ggml-org/llama.cpp) with a local GPT-OSS model, copied the model ID from the local server, and used a placeholder API key because the endpoint did not require a real one.\n\nUse the custom OpenAI-compatible agent option, then set:\n\n```text\nAPI type: chat\nBase URL: your local OpenAI-compatible endpoint\nModel: the exact model ID reported by your local server\nParallelism: 1\n```\n\nParallelism at `1` is a reasonable starting point because a local model may already be using most of the available hardware.\n\n## Which one?\n\nBuzz agents normally start when someone mentions them, unless you configure a watcher or recurring behavior. It fits collaborative work where humans and agents share channels, and it can act as a visibility layer across several tools.\n\nPaperclip is more structured. Heartbeats wake agents up, the org chart passes work down, and budgets limit what each agent or company can spend. I would look at it first for a solo operation where recurring work needs to happen without a person sitting in the chat.\n\nBuzz does not add its own dollar budgets. Spending follows whatever limits exist in the connected harness or model provider. Paperclip is API-first and puts per-agent and company budgets directly into the workflow.\n\nThey can overlap, but I would start with one small chore and add more after the workflow is working. My first Paperclip job was GitHub issue triage, while Buzz became the place where I could see updates and directly ask agents to build.\n",[],[],"25ee02a8-7a57-419f-a274-d01981b6447c",2020,"autonomous-ai-and-agent-orchestration-buzz-paperclip","REST API Crash Course - Full ElysiaJS CRUD API Beginner Tutorial","## Timestamps\n\n- `00:00` - Intro\n- `00:36` - A look at Elysia\n- `01:49` - Video overview\n- `02:52` - What is bun?\n- `03:58` - Installation\n- `06:14` - Create a Repo\n- `07:57` - Creating a route or endpoint\n- `12:15` - Details Endpoint\n- `15:12` - Automatic documentation\n- `16:51` - Data validation\n- `19:57` - Working with a Database\n- `26:37` - Updating and deleting data\n- `30:41` - Delete Endpoint\n- `33:14` - Update with PUT\n- `34:13` - Errors\n- `37:09` - Object Relational Mappers (ORM)\n- `42:42` - Postgres and Docker installation\n- `44:03` - psql\n- `46:04` - Get Data with Drizzle\n- `47:22` - Insert with Drizzle\n- `48:49` - Deleting with Drizzle\n- `49:55` - Updating with Drizzle\n- `50:38` - Type Validation\n- `52:34` - Array Destructuring\n- `52:49` - Put vs Patch\n- `54:16` - What's next?\n\nFull code for this video is on GitHub: [https://github.com/CalebCurry/elysia](https://github.com/CalebCurry/elysia)\n\n[Elysia](https://elysiajs.com) is a backend TypeScript framework for building APIs, and it runs on [Bun](https://bun.com) instead of Node. Bun is a JavaScript runtime, so you can think of it as an alternative to Node.\n\nWhat Elysia gives you out of the box:\n\n- request validation built in, so the data you work with matches your rules at runtime AND is typed while you write the code\n- type safety all the way through, including types shared between client and server\n- first class OpenAPI documentation from the very first route\n\nThe documentation page specs out the whole API, so it's what you hand to whoever builds a frontend, a client library, or an MCP server against it (or an agent doing the same).\n\n## What we're building\n\nAn API for running marketing campaigns. A campaign has a name and a due date, and later on it could have content pieces hanging off of it (social posts, blogs, newsletters, whatever).\n\nFor this video it's just campaigns, and by the end we'll have full CRUD:\n\n```\nGET /api/v1/campaigns\nGET /api/v1/campaigns/:id\nPOST /api/v1/campaigns\nPUT /api/v1/campaigns/:id\nDELETE /api/v1/campaigns/:id\n```\n\nWe start on mock data, move to SQLite with raw SQL, then finish on Postgres through an ORM (Drizzle).\n\n## What is Bun\n\nBun is on v1.4 as I record this. The first 1.0 came out September 8th, 2023, so it's a few years old and past the point where it's a bunch of bugs. It's got almost 100,000 stars on GitHub and some pretty big users: Claude Code ships as a Bun single file executable, Midjourney runs notifications through Bun's WebSocket server, and Railway built its serverless functions on it. Bun is also part of Anthropic now, which I didn't know until I was researching this.\n\nIt runs TypeScript files directly, which takes a chunk of the usual TypeScript setup off your plate.\n\n> [!tip]\n> Bun strips the types and runs the JavaScript underneath, it does NOT typecheck. If you want type errors reported you still run `tsc --noEmit` (or lean on your editor).\n\n## Installation\n\nMac and Linux:\n\n```bash\ncurl -fsSL https://bun.com/install | bash\n```\n\nWindows (PowerShell):\n\n```bash\npowershell -c \"irm bun.sh/install.ps1|iex\"\n```\n\nI keep all my projects in one folder, so make a directory for the project and scaffold in to it. The project is called `omnicopy` (copy as in marketing text, and it's supposed to be everywhere, I don't know, naming is hard):\n\n```bash\nmkdir omnicopy\ncd omnicopy\nbun create elysia .\n```\n\nThe `.` means the current directory. If you'd rather it make the folder for you, give it the name instead: `bun create elysia omnicopy`.\n\nThen run it:\n\n```bash\nbun run src/index.ts\n```\n\nIf you get `Failed to start server. Is port 3000 in use?` something else is already on 3000. Kill it, or change the port in `src/index.ts`.\n\nOpen [http://localhost:3000](http://localhost:3000) and you get \"Hello Elysia\". The whole server is in `src/index.ts`:\n\n```typescript\nimport { Elysia } from \"elysia\";\n\nconst app = new Elysia().get(\"/\", () => \"Hello Elysia\").listen(3000);\n\nconsole.log(\n `🦊 Elysia is running at ${app.server?.hostname}:${app.server?.port}`\n);\n```\n\nChange the string and refresh, and nothing happens. `bun run` doesn't watch for changes. Use the dev script instead:\n\n```bash\nbun dev\n```\n\nThat runs `bun run --watch src/index.ts`, which comes from the `dev` script in `package.json`. Same idea as `npm run dev` in Node, it's just a convention.\n\n## Create a Repo\n\nThe scaffold already made a git repo and a `.gitignore`, so commit right away:\n\n```bash\ngit add .\ngit commit -m \"initial commit\"\n```\n\nThen create a repo on GitHub and push to it.\n\nThe generated `.gitignore` is decent, but it's missing two things we're about to create: database files and a plain `.env` (it only has the scoped ones like `.env.local`). Add these at the top:\n\n```\n.env\n*.db\n```\n\nA `.env` is where anything sensitive goes, like a database password, and the `.gitignore` is what keeps it out of the repo. In VS Code the file goes from green to gray once it's ignored, which is a quick way to check.\n\n```bash\ngit add .\ngit commit -m \"update .gitignore\"\ngit push origin main\n```\n\n## Creating a route or endpoint\n\nSome vocabulary first. A **resource** is the thing you're working with, so campaigns. An **endpoint** is any one thing you can do with that resource: GET it, POST it, PUT it, DELETE it. They'll all share the same path, just with different HTTP methods.\n\nWe'll mock the data with an array first, so the API side can get built without a database in the way, then swap in the database after. At the top of `src/index.ts`:\n\n```typescript\nconst campaigns = [\n {\n campaignId: 1,\n name: 'Summer Sale',\n dueDate: new Date(),\n createdAt: new Date(),\n },\n {\n campaignId: 2,\n name: 'Black Friday',\n dueDate: new Date(),\n createdAt: new Date(),\n },\n];\n```\n\nEvery route is going to live under `/api/v1`, and instead of typing that on each one you pass a `prefix` to the constructor. I also put each chained method on its own line so I don't lose any of them, with `.listen()` always last:\n\n```typescript\nconst app = new Elysia({ prefix: '/api/v1' })\n .get('/campaigns', () => {\n return { data: campaigns };\n })\n .get('/', () => 'Hello Caleb!')\n .listen(3000);\n```\n\nWith the prefix, `localhost:3000` is now a 404 and the hello route moved to [http://localhost:3000/api/v1](http://localhost:3000/api/v1). The campaigns are at [http://localhost:3000/api/v1/campaigns](http://localhost:3000/api/v1/campaigns). Returning a plain object sends it back as JSON.\n\nYou could write `{ campaigns }` (shorthand when the key and variable name match), but I wrap everything in `data`. It's the same on every endpoint, it works for one item or a list, and it leaves room for other attributes later, like pagination info.\n\n## Details Endpoint\n\nNow one campaign by id. The `:id` in the path is a parameter, and it shows up on `params`:\n\n```typescript\n.get('/campaigns/:id', ({ params: { id }, status }) => {\n const campaign = campaigns.find((c) => c.campaignId == Number(id));\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n})\n```\n\nThe handler gets one argument, the **context**, which describes the request. You could write `(context) => context.params.id`, the parentheses above are just destructuring that same object to grab `params` (and `id` out of it) plus `status`.\n\n`id` comes in as a string, so it gets converted with `Number()` for now. Try `/api/v1/campaigns/1`, `/2`, and something that doesn't exist to see the 404.\n\nHere's what else is on the context:\n\n- `body`, `query`, `params`, `headers`, `cookie`, `store` for request data\n- `redirect`, `status`, `set` for building the response\n- `request`, `server`, `path` for the raw request info\n\nMore on the [handler and context](https://elysiajs.com/essential/handler) in the docs.\n\n> [!tip]\n> Coming from Express, the shape is different. Express gives you `(req, res)` and you call `res.status(404).json(...)`. In Elysia you get one context object and you RETURN the response. A plain object goes out as JSON with a 200, and `status()` is how you pick a different code.\n\n```bash\ngit add .\ngit commit -m \"details api example\"\n```\n\n## Automatic documentation\n\nTwo routes is already enough to get a documentation page:\n\n```bash\nbun add @elysia/openapi\n```\n\n```typescript\nimport openapi from '@elysia/openapi';\n\nconst app = new Elysia({ prefix: '/api/v1' })\n .use(openapi())\n```\n\nThen go to [http://localhost:3000/api/v1/openapi](http://localhost:3000/api/v1/openapi). It's under `/api/v1` because of the prefix, not `/openapi` like the docs show.\n\nYou can send requests right from this page. Open the `:id` endpoint, give it `1`, run it, and the response shows up below, so you don't have to stare at raw JSON in the browser. I've worked with other languages and frameworks where getting a spec like this built out took a lot of time even with a library helping, so this one is pretty nice.\n\n> [!tip]\n> You'll see a lot of older tutorials installing `@elysiajs/swagger`. The [OpenAPI plugin](https://elysiajs.com/plugins/openapi) replaced it. The plugins are also published under both the `@elysia/` and `@elysiajs/` scopes, and the docs use `@elysia/` now.\n\n## Data validation\n\nThis is checking data at RUNTIME. TypeScript only checks the code you write, it can't stop a user from sending you the wrong thing, so validation is what makes sure requests actually have the type and structure you expect.\n\nImport `t` and give the route a third argument, an object describing what you expect:\n\n```typescript\nimport { Elysia, t } from 'elysia';\n\n.get(\n '/campaigns/:id',\n ({ params: { id }, status }) => {\n const campaign = campaigns.find((c) => c.campaignId == id);\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n },\n)\n```\n\nThe `Number()` cast is gone. The schema says `id` is a number, so Elysia converts it before your handler runs, and TypeScript knows it's a number too.\n\nNow try `/api/v1/campaigns/hello`:\n\n```\n{\n \"type\": \"validation\",\n \"on\": \"params\",\n \"property\": \"/id\",\n \"message\": \"Expected union value\",\n \"summary\": \"Property 'id' should be one of: 'numeric', 'number'\",\n ...\n}\n```\n\nWithout the schema that same request was just a 404 not found, which doesn't tell the caller anything. And if you go back to the docs page, the expected structure for `id` is described there now, so whoever uses the API isn't guessing.\n\n`t` is a fork of [TypeBox](https://github.com/sinclairzx81/typebox). If you already know Zod, or already have Zod schemas, Elysia supports those too through [Standard Schema](https://elysiajs.com/essential/validation), you don't have to use `t`.\n\n90% of what you'll write looks like this:\n\n```typescript\n{\n params: t.Object({ id: t.Number() }),\n query: t.Object({ limit: t.Optional(t.Number()) }),\n body: t.Object({\n name: t.String(),\n dueDate: t.Optional(t.String())\n })\n}\n```\n\n`params` is the URL, `query` is the stuff after the `?`, and `body` is the POST or PUT payload. There's a lot more in the [validation docs](https://elysiajs.com/essential/validation), but once you know what you're trying to allow it's easy to look up the exact type.\n\n## Working with a Database\n\nI don't want to build every endpoint on the array and then go back and change all of them, so the database comes in now, before POST, PUT and DELETE exist. Bun has SQLite built in, so there's nothing to install:\n\n```typescript\nimport { Database } from 'bun:sqlite';\n\nconst db = new Database('campaigns.db');\n\ndb.run(`\n CREATE TABLE IF NOT EXISTS campaigns (\n campaign_id INTEGER PRIMARY KEY AUTOINCREMENT,\n name TEXT NOT NULL,\n due_date TEXT,\n created_at TEXT NOT NULL\n )\n`);\n```\n\nThis runs every time the server starts (which with `bun dev` is every save), and that's fine because of `IF NOT EXISTS`. Take that part out and you'll get this on the next save:\n\n```\nSQLiteError: table campaigns already exists\n```\n\nColumns are snake_case, the SQL convention. SQLite stores dates as text, and `NOT NULL` means required, so `due_date` is the only optional column.\n\n### Seeding\n\n**Seeding** is putting starter data in the tables, usually for development (or something like an admin user in production). Only do it if the table is empty, otherwise you get a new row every restart:\n\n```typescript\nif (!db.query('SELECT 1 FROM campaigns').get()) {\n db.run(`INSERT INTO campaigns (name, created_at) VALUES (?, ?)`, [\n 'Cyber Monday',\n new Date().toISOString(),\n ]);\n}\n```\n\n`SELECT 1 ... .get()` gives you nothing back when there are no rows, so `!` flips that to true and we insert. We don't name `campaign_id` (the database assigns it) or `due_date` (optional).\n\nThose `?` marks are placeholders. The values get passed in separately in the array, and SQLite binds them as data instead of pasting them in to the SQL string, which is how you avoid SQL injection. Never build a query by sticking user input in to the string.\n\nNow delete (or comment out) the mock `campaigns` array and point the two GET routes at the database:\n\n```typescript\n.get('/campaigns', () => {\n return {\n data: db.query('SELECT * FROM campaigns').all(),\n };\n})\n.get(\n '/campaigns/:id',\n ({ params: { id }, status }) => {\n const campaign = db\n .query('SELECT * FROM campaigns WHERE campaign_id = ?')\n .get(id);\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n },\n)\n```\n\n`.all()` returns every row, `.get()` returns the first one (or `null`). Test both from the docs page and you get the Cyber Monday row back.\n\n### Aliases\n\nLook at the JSON though, it says `campaign_id` and `due_date`. The API is leaking the database's snake_case. Not the end of the world, but the easy fix is an alias on each column with `AS`:\n\n```typescript\n.get('/campaigns', () => {\n return {\n data: db\n .query(\n 'SELECT campaign_id AS campaignId, name, due_date AS dueDate, created_at AS createdAt FROM campaigns',\n )\n .all(),\n };\n})\n.get(\n '/campaigns/:id',\n ({ params: { id }, status }) => {\n const campaign = db\n .query(\n 'SELECT campaign_id AS campaignId, name, due_date AS dueDate, created_at AS createdAt FROM campaigns WHERE campaign_id = ?',\n )\n .get(id);\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n },\n)\n```\n\nIt's a bit of extra typing. An ORM can do this conversion for you automatically, which we get to later.\n\n## Updating and deleting data\n\nTime to create data. POST goes on the same `/campaigns` path as the \"get all\" route, since you're adding to that collection:\n\n```typescript\n.post(\n '/campaigns',\n ({ body, status }) => {\n const campaign = db\n .query(\n `\n INSERT INTO campaigns (name, due_date, created_at)\n VALUES (?, ?, ?)\n RETURNING campaign_id AS campaignId, name, due_date AS dueDate, created_at AS createdAt\n `,\n )\n .get(body.name, body.dueDate ?? null, new Date().toISOString());\n\n return status(201, { data: campaign });\n },\n {\n body: t.Object({\n name: t.String(),\n dueDate: t.Optional(t.String({ format: 'date' })),\n }),\n },\n)\n```\n\n`RETURNING` hands back the row that was just created, including the id the database picked, and `.get()` is where the values for the three `?` go. `dueDate` is optional so it defaults to `null`. We send back `201 Created` with the new campaign.\n\nThe `format: 'date'` makes `dueDate` a calendar date, year-month-day like `2026-11-27`. Send something else and you get:\n\n```\nExpected string to match 'date' format\n```\n\n`createdAt` is a full timestamp on purpose. It's logging when the row was made and we never touch it, while the due date is something the user sets.\n\n## Delete Endpoint\n\nDELETE uses the same path as the details endpoint, and the same `params` schema:\n\n```typescript\n.delete(\n '/campaigns/:id',\n ({ params: { id }, status }) => {\n const { changes } = db.run(\n 'DELETE FROM campaigns WHERE campaign_id = ?',\n [id],\n );\n if (changes === 0) return status(404);\n return status(204);\n },\n { params: t.Object({ id: t.Number() }) },\n)\n```\n\n`db.run()` gives back an object with `changes`, how many rows were affected. Zero means there was nothing to delete, so 404. Otherwise `204 No Content`.\n\nDelete id 2 from the docs page and you get a 204, run it again and it's a 404, and it's gone from the list.\n\n> [!tip]\n> In the video I first wrote `return 204` instead of `return status(204)`. That sends back a 200 with the literal number `204` as the body. Returning a number is just data, `status()` is what actually sets the code.\n\n## Update with PUT\n\nGive this one a try yourself before looking. It's the same patterns as above, update the row and return the updated campaign:\n\n```typescript\n.put(\n '/campaigns/:id',\n ({ params: { id }, body, status }) => {\n const campaign = db\n .query(\n `UPDATE campaigns SET name = ?, due_date = ? WHERE campaign_id = ?\n RETURNING campaign_id AS campaignId, name, due_date AS dueDate, created_at AS createdAt`,\n )\n .get(body.name, body.dueDate ?? null, id);\n\n if (!campaign) return status(404);\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n body: t.Object({\n name: t.String(),\n dueDate: t.Optional(t.String({ format: 'date' })),\n }),\n },\n)\n```\n\nGrab an id from the list, PUT a new name (I renamed mine to \"Black Friday Cyber Monday\"), and the updated row comes back with the same id. The attributes get replaced but the id stays, so it's logically still the same campaign. `created_at` isn't in the `SET`, so that stays too.\n\n```bash\ngit add .\ngit commit -m \"fix delete status code and add put\"\n```\n\n## Errors\n\nThere's default error handling already. Send a POST with `\"name\": 5` and you get a big verbose validation error. If you're the one building the frontend that's probably fine, it gives you all the details you need. For a user facing API you'll probably want to control it, and that's `.onError()`, chained right after `.use(openapi())`:\n\n```typescript\n.onError(({ code, error, status }) => {\n if (code === 'NOT_FOUND') return status(404, { error: 'Not Found' });\n if (code === 'VALIDATION')\n return status(422, { error: 'Bad request data' });\n console.error(error);\n return status(500, { error: 'Something went wrong, try again later' });\n})\n```\n\n`422 Unprocessable Content` is the common code for invalid data. I wrap each message in an object with an `error` key rather than sending back a plain string, same reason as the `data` wrapper.\n\nThe last line is the catch-all. Anything that isn't a 404 or a validation problem gets logged on the server with `console.error` and the client gets a generic 500, so you're not leaking internals. To see it, put a `throw new Error()` in the PUT handler and send a valid request (an invalid one fails validation before your handler ever runs).\n\nIf you're happy with the default messages, you don't need any of this.\n\n## Object Relational Mappers (ORM)\n\nAn **ORM** (object relational mapper) maps the objects in your code to rows in the database, so you work with the database through code instead of writing the SQL yourself. There are pros and cons you can go research, but I'd generally recommend one unless you specifically need to hand write your SQL.\n\n[Prisma](https://www.prisma.io) is a great option. We're going with [Drizzle](https://orm.drizzle.team), which is probably the recommended option for Elysia (it has its own [integration page](https://elysiajs.com/integrations/drizzle) in the Elysia docs). The reason is `drizzle-typebox`. Elysia's `t` is a fork of TypeBox, and `drizzle-typebox` turns a Drizzle table in to TypeBox schemas, so you get request validation straight from your table definition without describing the same shape twice.\n\nIt's hard to see why that matters until you do it, so let's install it:\n\n```bash\nbun add drizzle-orm drizzle-typebox\nbun add -D drizzle-kit\n```\n\n`drizzle-kit` is the CLI that creates the tables, so it's a dev dependency.\n\nWe're moving to Postgres at the same time, so the file structure changes a bit:\n\n```\nomnicopy/\n .env DATABASE_URL, gitignored\n drizzle.config.ts settings for the drizzle-kit CLI\n src/\n schema.ts the table definitions\n index.ts the server\n```\n\n`drizzle.config.ts` goes at the top level next to `package.json`. It tells the CLI where the schema is, turns on automatic snake_case conversion, and reads the connection string from `.env`:\n\n```typescript\n// needed for drizzle kit (CLI)\n\nimport { defineConfig } from 'drizzle-kit';\n\nexport default defineConfig({\n schema: './src/schema.ts',\n dialect: 'postgresql',\n casing: 'snake_case',\n dbCredentials: {\n url: process.env.DATABASE_URL!,\n },\n});\n```\n\nBun loads `.env` automatically, so there's no `dotenv` package. For now just put a placeholder in `.env`, we'll fill in the real value once Postgres is running:\n\n```\nDATABASE_URL=\n```\n\n`src/schema.ts` is where the `CREATE TABLE` moves to, written as TypeScript:\n\n```typescript\nimport { pgTable, serial, text, date, timestamp } from 'drizzle-orm/pg-core';\n\nexport const campaigns = pgTable('campaigns', {\n campaignId: serial().primaryKey(),\n name: text().notNull(),\n dueDate: date(),\n createdAt: timestamp().notNull().defaultNow(),\n});\n```\n\nThe properties are camelCase now. With `casing: 'snake_case'` Drizzle converts `campaignId` to `campaign_id` going in to the database and back again coming out, so all those `AS` aliases go away.\n\n`dueDate` is a `date()` with no `notNull()`, so it's optional. `createdAt` is a `timestamp()`, a point in time the database manages for you, and `defaultNow()` means Postgres fills it in when the row gets created so we stop passing `new Date().toISOString()` around.\n\nNow in `src/index.ts`, swap the SQLite setup for a Drizzle connection. The `new Database(...)`, the `CREATE TABLE`, and the seed block all get deleted, along with the `bun:sqlite` import:\n\n```typescript\nimport { drizzle } from 'drizzle-orm/bun-sql';\nimport * as schema from './schema';\nimport { campaigns } from './schema';\n\nconst db = drizzle(process.env.DATABASE_URL!, { schema, casing: 'snake_case' });\n```\n\n`drizzle-orm/bun-sql` uses Bun's built in Postgres client. The `casing` gets repeated here because the config file is only for the CLI, and your queries need to know about the conversion too. The `!` tells TypeScript to assume the env variable has a value, otherwise it complains that it's `string | undefined`.\n\nThen update the first route. Queries go over the network now, so the handler is `async` and the query gets an `await`:\n\n```typescript\n.get('/campaigns', async () => {\n return {\n data: await db.select().from(campaigns),\n };\n})\n```\n\nSend a request and you get `Something went wrong, try again later` from our `onError`, because there's no Postgres database yet.\n\n## Postgres and Docker installation\n\nYou can install Postgres directly, but I like running it in a Docker container. It's by far the easiest way to set it up, and it's easy to have a separate one per project. You'll need [Docker](https://www.docker.com/products/docker-desktop/) installed.\n\n`drizzle-kit` also needs a Postgres driver of its own (your app uses Bun's client, the CLI doesn't), so add `pg` as a dev dependency:\n\n```bash\nbun add -D pg\n```\n\nThen start Postgres:\n\n```bash\ndocker run --name campaigns-db -e POSTGRES_PASSWORD=devpassword -e POSTGRES_USER=omnicopy -e POSTGRES_DB=campaigns -p 5432:5432 -d postgres:18\n```\n\n- `--name campaigns-db` so you can refer to the container by name\n- the `-e` variables create the user, password, and database the first time the container starts\n- `-p 5432:5432` maps a port on your machine to Postgres inside the container\n- `-d` runs it detached so you get your terminal back\n\nIf you already have something on 5432 (I usually do), change only the FIRST number, like `-p 5435:5432`. The second one is the port inside the container and stays the same.\n\nCheck it's running:\n\n```bash\ndocker ps\n```\n\n## psql\n\nYou don't need Postgres installed on your machine to run SQL against it, there's `psql` inside the container:\n\n```bash\ndocker exec -it campaigns-db psql -U omnicopy -d campaigns\n```\n\n```sql\nSELECT 5 + 5;\n```\n\nThat gives back `10`. A couple of `psql` commands worth knowing: `\\dt` lists the tables (there aren't any yet), and `\\q` quits. You'll probably want to write these commands down somewhere.\n\nNow fill in `.env`. Every piece of the connection string comes from the `docker run` flags, user, password, host, port, and database:\n\n```\nDATABASE_URL=postgresql://omnicopy:devpassword@localhost:5432/campaigns\n```\n\nUse whatever port you mapped (mine was `5435`). Restart the server and try the request again. Now the error is:\n\n```\nrelation \"campaigns\" does not exist\n```\n\nSo it's working, it's just broken, if that makes sense. We connected, the database just doesn't have the table yet. I split the terminal so the server keeps running on one side, and on the other:\n\n```bash\nbunx drizzle-kit push\n```\n\n```\nReading config file '.../drizzle.config.ts'\nUsing 'pg' driver for database querying\n[✓] Pulling schema from database...\n[✓] Changes applied\n```\n\nSend the request again and you get `{\"data\":[]}`. The container is running, the app is connected through Drizzle, and the table exists.\n\n`push` makes the database match your schema directly. That's fine while it's one table on your own machine. Once you have a real database that other people depend on you'd switch to migrations (`drizzle-kit generate` and `drizzle-kit migrate`), which write versioned SQL files you commit. There's more on that in the [Drizzle docs](https://orm.drizzle.team/docs/drizzle-kit-push).\n\n## Get Data with Drizzle\n\nThe details endpoint, `async` and `await` again, with `eq` for the `WHERE`:\n\n```typescript\nimport { eq } from 'drizzle-orm';\n\n.get(\n '/campaigns/:id',\n async ({ params: { id }, status }) => {\n const [campaign] = await db\n .select()\n .from(campaigns)\n .where(eq(campaigns.campaignId, id));\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n },\n)\n```\n\n`db.select()` always gives back an array, even when you're looking up one id. That's what the `[campaign]` is for, more on it in a second.\n\n## Insert with Drizzle\n\n```typescript\n.post(\n '/campaigns',\n async ({ body, status }) => {\n const [campaign] = await db\n .insert(campaigns)\n .values(body)\n .returning();\n return status(201, { data: campaign });\n },\n {\n body: t.Object({\n name: t.String(),\n dueDate: t.Optional(t.String({ format: 'date' })),\n }),\n },\n)\n```\n\n`.returning()` does the same job as `RETURNING` in the raw SQL, hands you back the new row. Create a few from the docs page (I clicked send a few times, which is fine, now there's stuff to delete).\n\nAn empty string for `dueDate` gets rejected with `Bad request data`. Leave `dueDate` off completely and it works, since it's nullable, but `\"\"` isn't null and it isn't a valid date.\n\nThat error message isn't very helpful though. Our `onError` hides the details and doesn't log validation errors, which makes building harder. While you're developing you can just comment it out and get Elysia's full validation errors back:\n\n```typescript\n// .onError(({ code, error, status }) => {\n// if (code === 'NOT_FOUND') return status(404, { error: 'Not Found' });\n// if (code === 'VALIDATION')\n// return status(422, { error: 'Bad request data' });\n// console.error(error);\n// return status(500, { error: 'Something went wrong, try again later' });\n// })\n```\n\nYou could also switch it on only outside of development with an environment variable, but I don't want to get off topic.\n\n## Deleting with Drizzle\n\n```typescript\n.delete(\n '/campaigns/:id',\n async ({ params: { id }, status }) => {\n const deleted = await db\n .delete(campaigns)\n .where(eq(campaigns.campaignId, id))\n .returning();\n if (deleted.length === 0) return status(404);\n return status(204);\n },\n { params: t.Object({ id: t.Number() }) },\n)\n```\n\nThere's no `changes` count anymore. With `.returning()` you get an array of the deleted rows, so an empty array means nothing matched and it's a 404. Delete id 2, you get a 204, do it again and it's a 404.\n\n## Updating with Drizzle\n\n```typescript\n.put(\n '/campaigns/:id',\n async ({ params: { id }, body, status }) => {\n const [campaign] = await db\n .update(campaigns)\n .set(body)\n .where(eq(campaigns.campaignId, id))\n .returning();\n\n if (!campaign) return status(404);\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n body: t.Object({\n name: t.String(),\n dueDate: t.Optional(t.String({ format: 'date' })),\n }),\n },\n)\n```\n\nUpdate campaign 1 with a new name and it works. Notice the due date stayed though, even though we didn't send one. That's more like a PATCH, which we fix below.\n\n## Type Validation\n\nThose `t.Object` bodies on POST and PUT describe the exact same shape as the table. `createInsertSchema` from `drizzle-typebox` builds that validation schema from the table instead:\n\n```typescript\nimport { createInsertSchema } from 'drizzle-typebox';\n\nconst _insertCampaign = createInsertSchema(campaigns, {\n dueDate: (schema) => t.String({ ...schema, format: 'date' }),\n});\nconst campaignBody = t.Omit(_insertCampaign, ['campaignId', 'createdAt']);\n```\n\n`_insertCampaign` is an in-between step (hence the underscore). It's everything you could insert in to the table, including `campaignId` and `createdAt`. The database owns those two, so `t.Omit` takes them out. Hover over `campaignBody` and it's `name`, required, and `dueDate`, optional.\n\n> [!tip]\n> The video uses `createInsertSchema(campaigns)` with no second argument. That quietly drops the `format: 'date'` check we had on the hand written body, because a Postgres `date()` column just becomes a plain string schema. With the original version, `\"dueDate\": \"next tuesday\"` passes validation, hits Postgres, and the client gets a 500 (with `onError` commented out, the raw `Failed query: insert into \"campaigns\" ...` SQL comes back in the response). The second argument puts the date format back, and the callback form keeps `dueDate` optional and nullable. Without the callback, passing `t.String(...)` directly makes `dueDate` required.\n\n> [!tip]\n> Assign the schema to a variable like `_insertCampaign` rather than calling `createInsertSchema` inline in a route. The [Elysia Drizzle docs](https://elysiajs.com/integrations/drizzle) call out that inlining it can send TypeScript in to an infinite type instantiation loop.\n\nNow both routes use it:\n\n```typescript\n{\n body: campaignBody,\n}\n```\n\nPUT keeps its `params` as well. Change a column in `schema.ts` and the validation, the types, and the docs page all follow.\n\n## Array Destructuring\n\nQuick one I missed at first. Every select, insert, and update in Drizzle gives back an array, so a single row needs pulled out with array destructuring, `const [campaign] = await ...`, which grabs the first element. Without the brackets, `campaign` is an array. An empty array is still truthy, so the 404 check never fires and you'd send back `{ data: [] }`.\n\n## Put vs Patch\n\nA **PUT** is supposed to replace the whole resource, and a **PATCH** changes only the fields you send. `.set(body)` behaves like a PATCH: Drizzle skips keys that are `undefined`, so leaving `dueDate` out of the request left the old due date in place.\n\nTo make it a real PUT, set each column explicitly and default the due date to `null`:\n\n```typescript\n.set({\n name: body.name,\n dueDate: body.dueDate ?? null,\n})\n```\n\nNow a PUT without `dueDate` clears it, and a PUT with one sets it.\n\nHere's the full `src/index.ts` at the end:\n\n```typescript\nimport openapi from '@elysia/openapi';\nimport { Elysia, t } from 'elysia';\nimport { drizzle } from 'drizzle-orm/bun-sql';\nimport { eq } from 'drizzle-orm';\nimport { campaigns } from './schema';\nimport * as schema from './schema';\nimport { createInsertSchema } from 'drizzle-typebox';\n\n// needed for drizzle orm\nconst db = drizzle(process.env.DATABASE_URL!, { schema, casing: 'snake_case' });\n\nconst _insertCampaign = createInsertSchema(campaigns, {\n dueDate: (schema) => t.String({ ...schema, format: 'date' }),\n});\nconst campaignBody = t.Omit(_insertCampaign, ['campaignId', 'createdAt']);\n\nconst app = new Elysia({ prefix: '/api/v1' })\n .use(openapi())\n // .onError(({ code, error, status }) => {\n // if (code === 'NOT_FOUND') return status(404, { error: 'Not Found' });\n // if (code === 'VALIDATION')\n // return status(422, { error: 'Bad request data' });\n // console.error(error);\n // return status(500, { error: 'Something went wrong, try again later' });\n // })\n .get('/campaigns', async () => {\n return {\n data: await db.select().from(campaigns),\n };\n })\n .get(\n '/campaigns/:id',\n async ({ params: { id }, status }) => {\n const [campaign] = await db\n .select()\n .from(campaigns)\n .where(eq(campaigns.campaignId, id));\n if (!campaign) {\n return status(404);\n }\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n },\n )\n .post(\n '/campaigns',\n async ({ body, status }) => {\n const [campaign] = await db\n .insert(campaigns)\n .values(body)\n .returning();\n return status(201, { data: campaign });\n },\n {\n body: campaignBody,\n },\n )\n .delete(\n '/campaigns/:id',\n async ({ params: { id }, status }) => {\n const deleted = await db\n .delete(campaigns)\n .where(eq(campaigns.campaignId, id))\n .returning();\n if (deleted.length === 0) return status(404);\n return status(204);\n },\n { params: t.Object({ id: t.Number() }) },\n )\n .put(\n '/campaigns/:id',\n async ({ params: { id }, body, status }) => {\n const [campaign] = await db\n .update(campaigns)\n .set({\n name: body.name,\n dueDate: body.dueDate ?? null,\n })\n .where(eq(campaigns.campaignId, id))\n .returning();\n\n if (!campaign) return status(404);\n return { data: campaign };\n },\n {\n params: t.Object({ id: t.Number() }),\n body: campaignBody,\n },\n )\n .get('/', () => 'Hello Caleb!')\n .listen(3000);\n\nconsole.log(\n `🦊 Elysia is running at ${app.server?.hostname}:${app.server?.port}`,\n);\n```\n\n> [!tip]\n> This matches the [repo](https://github.com/CalebCurry/elysia) with two changes: the `dueDate` date format fix from the Type Validation section, and the leftover `import { Database } from 'bun:sqlite'` removed, since nothing uses SQLite anymore.\n\n## What's next?\n\nFrom here the next steps are database relationships (the content pieces that hang off a campaign), using this API from a frontend, and the approach Elysia recommends for that. Leave a comment on the video if you want that one. The [Elysia docs](https://elysiajs.com) are good and pretty short if you want to keep going on your own.",[],[],"5d00adf4-f857-422a-bb85-dca1c9d7e014",3298,"rest-api-crash-course-full-elysiajs-crud-api-beginner-tutorial",{"_200":258,"_48":207,"_208":149,"_23":210,"_211":255,"_212":213,"_214":-5,"_215":-5,"_216":-5,"_217":-5},"faviconUrl","tenantName","externalCommunityEnabled","externalCommunityUrl","https://calcur.tech/community","contactEmail","isPrivateTenant","hideGeneratedBranding","studentPreview","facebookPixelId","trackingPixels",[],"trackingTenantEnabled","trackingConsentMode","none","consentRegion","consentBannerNeeded","trackingIdentity","paypalCheckout","umamiWebsiteId","30134907-2cb0-4c56-b7cb-3cae8dd6f4f4","requestId","cle1::pwkkg-1793043146550-07abe311b2ee","isBot"]

Locked Content