DEV Community: Micael Miranda Inácio

Is “Vibe Coding” Real? I Built a Full-Stack App with AI Agents in 30 Days

Micael Miranda Inácio — Thu, 12 Mar 2026 04:55:35 +0000

Over the last few months, a new term has been circulating in developer communities: “vibe coding.”

Depending on who you ask, it's either:

the future of software development
pure hype that will disappear in a year
or the beginning of the end for developer jobs

Instead of debating it endlessly, I decided to run a simple experiment.

For one month, I would build and launch a real full-stack application using AI agents as development assistants.

The goal wasn’t to let AI build everything for me. Instead, I wanted to see:

How much faster development becomes with AI assistance
What parts of software engineering still require human thinking
Whether this workflow actually makes building products more enjoyable

The result of that experiment was Ninco, a personal finance dashboard that I built and launched in about 30 days.

The Experiment

The rules were simple:

Build a real product from scratch
Ship something usable
Use AI agents throughout the development process
Keep infrastructure costs minimal
Finish within 1 month

The goal wasn’t to prove that AI can replace developers.

Instead, I wanted to test whether AI could remove friction from development and allow me to focus more on architecture and product decisions.

The Stack

The project ended up using a modern full-stack setup.

AI Development Environment

Google Antigravity
AI models: Gemini 3.1, Claude Opus, Claude Sonnet 4.6

Frontend

Next.js
Shadcn UI
TanStack Query
Clerk

Backend

Fastify
Prisma ORM
PostgreSQL

Infrastructure

Docker
GitHub
Monorepo: pnpm workspaces

This stack allowed me to move quickly while keeping the system structured and scalable.

How AI Actually Helped

AI was incredibly helpful in several areas.

1. Boilerplate Generation

Modern development includes a lot of repetitive work:

CRUD endpoints
validation schemas
API handlers
form structures

AI agents dramatically sped up writing these pieces.

What normally takes hours could often be generated and refined in minutes.

2. Debugging

Instead of spending long periods digging through documentation or StackOverflow, AI helped quickly identify common mistakes, especially when integrating new libraries.

3. Rapid UI Iteration

I used AI to experiment with UI layouts, component variations, and styling tweaks much faster than I normally would. Sometimes, challenging the AI to create complete interfaces without many details, and the results really surprised me.

This made the UI development process feel much more fluid.

4. Documentation and Refactoring

AI also helped generate documentation and suggest refactors for clearer code structure. If you ask the AI "How to improve this component using the best programming practices for a better performance/security?" or even cite a specific methodology or concept that you want to be applied, the outcomes will be quite satisfactory.

Where AI Didn’t Help Much

Despite all the advantages, some areas still required human engineering decisions.

Architecture

Designing the system structure, deciding how the frontend communicates with the backend, and organizing the monorepo still required careful planning.

Many times, the AI generated very large files with too many functions, reduced performance, or struggled with dependency versions. However, the result is largely a product of how well you use AI. As a beginner in this workflow, I surely committed mistakes with my inputs, lack of contexts or misuse of AI Skills. I truly believe that with some more experience and technical knowledge, the AI can solve most of the architectural issues.

Database Design

Every application requires accurate data modeling.

Defining schemas, relationships, and constraints still required careful manual thinking. I left the first draft to the AI, but of course it won't know how you want to scale or very specific fields that each table should have unless you explicitly tell it, so I had to review and edit some parts.

Product Decisions

AI can help build features, but deciding what features should exist in the first place is still a human job. You can get some ideas asking Chat GPT, but the final decision is yours.

Understanding users and designing workflows remains a core product skill.

The Result: Ninco

After about a month, the experiment resulted in a complete full-stack application called Ninco.

Ninco is a modern personal finance dashboard designed to make money tracking simple and fast.

Some of the core features include:

Tracking income and expenses
Register transactions via AI chat
Multiple financial accounts
Custom categories with colors and icons
Advanced transaction filtering
Interactive financial charts
Data export (CSV, JSON, PDF)

The focus of the product is clarity and speed.

Instead of complex financial workflows, the goal is to make tracking finances feel simple and intuitive.

Screenshots and Demo

Ninco demo | Arcade

app.arcade.software

You can visit the app on: https://ninco.app

Lessons from the Experiment

After building a real product with AI assistance, a few things became very clear.

AI drastically speeds up repetitive coding

Boilerplate tasks that normally take hours can now be generated in minutes.

Architecture still matters

AI can generate code, but good system design still comes from human decisions.

AI works best as a collaborator

The most productive workflow wasn’t replacing development with AI.

It was pair-programming with it.

Shipping products is easier than ever

With modern frameworks, cloud infrastructure, and AI tools, a single developer can build surprisingly complex systems in a short time.

Final Thoughts

This experiment changed how I think about software development.

AI didn’t replace engineering work, but it amplified productivity and removed a lot of friction from the development process.

More importantly, it made building the project much more fun.

The result of this experiment is Ninco, which is now live and evolving. Check it out!

I’d Love Your Feedback

I'm curious to hear what other developers think.

Do you use AI in your development workflow?
Do you think “vibe coding” is a real shift in software engineering?
What features would you expect from a personal finance dashboard?

Feel free to share your thoughts or feedback — both about the experiment and the product.

🔒 Secure Your Sign-Ups: Email Validation in Node.js with Fastify, Prisma, and Nodemailer 📧

Micael Miranda Inácio — Sun, 23 Mar 2025 18:40:57 +0000

When building an authentication system, one crucial feature to implement is email validation before creating a user account. In this article, I'll show you how to implement this process using Fastify, Prisma, and Nodemailer to ensure that a user cannot register with someone else's email—whether by accident or on purpose.

The approach follows these steps:

Register the user data in a temporary table (unconfirmed users)
Send an email with a confirmation button
Confirm the email by clicking the button
Create the official user account
Delete temporary user data
Send a success email
Redirect the user

💾 Setting Up Data Structures

First, let's create our Prisma Schema:

model User {
  id         String   @id @default(uuid())
  name       String
  username   String   @unique
  email      String   @unique
  password   String   @db.VarChar(255)
  bio        String?
  createdAt  DateTime @default(now()) @map("created_at")
  userTypeId String   @map("user_type_id")
  userType   UserType @relation(fields: [userTypeId], references: [id])

  @@map("users")
}

model UnconfirmedUser {
  id         String   @id @default(uuid())
  name       String
  username   String   @unique
  email      String   @unique
  password   String   @db.VarChar(255)
  createdAt  DateTime @default(now()) @map("created_at")

  @@map("unconfirmed_users")
}

model UserType {
  id    String @id @default(uuid())
  type  String @unique
  users User[]

  @@map("user_types")
}

These three tables are all you need for a full authentication system.

For the user types, create a seed.ts file inside the /prisma folder that automatically creates the user types you'll need:

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

async function main() {
  // Create user types
  const commonUser = await prisma.userType.findFirst({
    where: { type: "common" },
  });
  if (!commonUser) {
    await prisma.userType.create({
      data: { type: "common" },
    });
  }
  const adminUser = await prisma.userType.findFirst({
    where: { type: "admin" },
  });
  if (!adminUser) {
    await prisma.userType.create({
      data: { type: "admin" },
    });
  }
  console.log("Admin and common user types created");
}

main()
  .then(async () => {
    await prisma.$disconnect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  });

To run the seed function, simply execute:

npx prisma db seed

Note: The seed function can create any data you need. In this example, it just creates two user types.

If you're struggling with setting up the Node.js application, check out these articles:

📝 Create Unconfirmed User

Now that the configuration is set, let's create the route. Inside the /users folder, create a file named create-unconfirmed-user.ts and paste the following code:

import bcrypt from "bcrypt";
import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import z from "zod";
import { ClientError } from "../../errors/client-error"; // Optional: you can switch to the default Error if preferred
import { prisma } from "../../lib/prisma"; // Setup as described in the recommended articles

export async function createUnconfirmedUser(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().post(
    "/users",
    {
      schema: {
        summary: "Create unconfirmed user and send confirmation email",
        tags: ["users"],
        body: z.object({
          name: z.string().min(4),
          username: z.string().min(4),
          email: z.string().email(),
          password: z.string().min(8).max(32),
        }),
      },
    },
    async (request, reply) => {
      const { name, username, email, password } = request.body;

      const existingUsername = await prisma.user.findFirst({
        select: { id: true },
        where: { username },
      });
      const existingEmail = await prisma.user.findFirst({
        select: { id: true },
        where: { email },
      });

      if (existingUsername) throw new ClientError("Username already in use");
      if (existingEmail) throw new ClientError("Email already in use");

      const hashedPassword = await bcrypt.hash(password, 10);

      // Create temporary user
      const user = await prisma.unconfirmedUser.create({
        data: {
          name,
          username,
          email,
          password: hashedPassword,
        },
      });

      return reply.send({ message: "ok" });
    }
  );
}

Actions required:

Install dependencies (check my package.json for reference).
Ensure your database is up to date.
Register this route in server.ts.

This route validates if the username and email are available, encrypts the password, and creates the unconfirmed user data.

✉️ Send Confirmation Email

Now, we'll set up email sending with Nodemailer.

Install the library:

   pnpm i nodemailer

Create a mail client in test mode:

   // src/lib/nodemailer.ts
   import nodemailer from "nodemailer";

   export async function getMailClient() {
     const account = await nodemailer.createTestAccount();

     const transporter = nodemailer.createTransport({
       host: "smtp.ethereal.email",
       port: 587,
       secure: false,
       auth: {
         user: account.user,
         pass: account.pass,
       },
     });

     return transporter;
   }

Create the email object with HTML content:

   // src/lib/emails/confirmation-email.ts
   export const confirmationEmail = (
     name: string,
     email: string,
     apiBaseUrl: string,
     userId: string
   ) => {
     return {
       from: {
         name: "Micael",
         address: "test@test.com",
       },
       to: {
         name: name,
         address: email,
       },
       subject: `Confirm your email to Micael's blog!`,
       html: `
         <div
           style="
             font-family: sans-serif;
             max-width: 400px;
             margin: 2rem auto;
             padding: 1rem;
             border-radius: 0.5rem;
           "
         >
           <h2>Welcome to Micael's Blog!</h2>
           <p style="padding: 1rem 0; line-height: 2rem">
             Click the link below to confirm your account creation.
           </p>
           <a
             href="${apiBaseUrl}/users/confirm-email?user_id=${userId}"
             style="
               text-decoration: none;
               background-color: #161f30;
               color: white;
               padding: 0.5rem 2rem;
               border-radius: 0.3rem;
               font-weight: bold;
             "
           >
             Confirm my email
           </a>
           <p style="padding: 1rem 0; line-height: 2rem; font-size: 14px">
             If you didn't register, please ignore this email.
           </p>
           <a href="#" target="_blank" style="color: black"> Micael's Blog </a>
         </div>
       `.trim(),
     };
   };

Tip: You can design the email in an HTML file and then paste the code into this function.

Now, let's call this email function inside create-unconfirmed-user.ts:

Import the dependencies:

   import nodemailer from "nodemailer";
   import { env } from "../../env";
   import { getMailClient } from "../../lib/nodemailer";
   import { confirmationEmail } from "../../lib/emails/confirmation-email";

Trigger the email at the end of the file:

   // Send confirmation email
   const userFirstName = name.split(" ")[0];
   const apiBaseUrl = env.API_BASE_URL;
   const mail = await getMailClient();
   const message = await mail.sendMail(
     confirmationEmail(userFirstName, email, apiBaseUrl, user.id)
   );
   console.log(nodemailer.getTestMessageUrl(message));

   return reply
     .status(202)
     .send({ message: "Confirmation email was sent successfully" });

Notes:

The confirmation email is sent using Nodemailer's native sendMail method.

The API base URL is obtained from your .env file, though you could also use a string (e.g., "http://localhost:3333") for testing.

The console log prints a URL to preview the email.

A status code 202 is returned to indicate the email was accepted for processing.

🧪 Test the Email

After setting everything up, test the route. You should see a link in the terminal that lets you preview the email. The confirmation button won't work yet — this will be implemented in the next step.

Example of how it should look like

👤 Create the User Account

When the user clicks the confirmation link, the API route validates the email and uses the user_id query parameter to create the user account. To improve security, the account creation should only proceed if it’s been less than 15 minutes since registration, based on the createdAt attribute of the unconfirmed user.

Separate the User Creation Function

// src/routes/users/create-account.ts
import { UnconfirmedUser } from "@prisma/client";
import { prisma } from "../../lib/prisma";

export default async function createAccount(existingUser: UnconfirmedUser) {
  const userType = await prisma.userType.findFirst({
    where: { type: "common" },
  });

  if (!userType) {
    throw new Error("User type 'common' not found.");
  }

  const user = await prisma.user.create({
    data: {
      name: existingUser.name,
      username: existingUser.username,
      email: existingUser.email,
      password: existingUser.password,
      userTypeId: userType.id,
    },
  });

  return user;
}

This function receives the unconfirmed user data, retrieves the common user type, and creates the official user record.

Create the API Route

// src/routes/users/confirm-email.ts
import dayjs from "dayjs";
import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import nodemailer from "nodemailer";
import z from "zod";
import { env } from "../../env";
import { ClientError } from "../../errors/client-error";
import { successEmail } from "../../lib/emails/success-email";
import { getMailClient } from "../../lib/nodemailer";
import { prisma } from "../../lib/prisma";
import createAccount from "./create-account";

export async function confirmEmail(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().get(
    "/users/confirm-email",
    {
      schema: {
        summary: "Confirm user email and create user account",
        tags: ["users"],
        querystring: z.object({
          user_id: z.string().uuid(),
        }),
      },
    },
    async (request, reply) => {
      const { user_id } = request.query;

      const existingUser = await prisma.unconfirmedUser.findFirst({
        where: { id: user_id },
      });

      if (!existingUser) throw new ClientError("User does not exist");

      // Check if registration is within 15 minutes
      if (
        dayjs(existingUser.createdAt).isBefore(dayjs().subtract(15, "minute"))
      ) {
        await prisma.unconfirmedUser.delete({
          where: { id: existingUser.id },
        });
        throw new ClientError("Registration expired, please try again");
      }

      const user = await createAccount(existingUser);

      await prisma.unconfirmedUser.delete({
        where: { id: existingUser.id },
      });

      const name = user.name.split(" ")[0];
      const mail = await getMailClient();
      // create another email function for success, just like the previous one
      const message = await mail.sendMail(successEmail(name, user.email));
      console.log(nodemailer.getTestMessageUrl(message));

      return reply.status(201).send({ userId: user.id });
      // Alternatively, you can redirect the user:
      // return reply.redirect(`${env.FRONTEND_BASE_URL}/success_page`);
    }
  );
}

Summary of Changes in This Step:

Validates the user_id from the query parameters.

Checks if the confirmation is within 15 minutes of registration and deletes the temporary data if expired.

Creates the official user account.

Deletes the unconfirmed user data.

Sends a success email and returns the new user ID.

Includes commented-out code as an alternative to redirect the user if you have a frontend.

📚 Conclusion

This article demonstrates a simple yet effective user registration system using Fastify, Prisma, and Nodemailer. By validating emails before creating an account, you enhance the security of your application without the need for many external services.

If you found this strategy helpful, please like and comment. Let me know what topic you'd like to see next!

✌️ For the complete source code, visit my repository: Blog by micaelmi

🧩 Reusable Form Components with Shadcn/UI: Cleaner Code, Better Experience

Micael Miranda Inácio — Fri, 14 Mar 2025 20:44:51 +0000

If you have ever used the shadcn/ui components with React Hook Form, you might have noticed that your form files can quickly become bloated. Although shadcn/ui offers great control over each part of a component, this flexibility often results in a giant file filled with repetitive markup. To solve this, I devised a way to create “default” versions of each form component that still allow for customization.

So, let's take a look at the standard input component implemented inside a form:

<FormField
  control={form.control}
  name="username"
  render={({ field }) => (
    <FormItem>
      <FormLabel>Username</FormLabel>
      <FormControl>
        <Input placeholder="shadcn" {...field} />
      </FormControl>
      <FormDescription>This is your public display name.</FormDescription>
      <FormMessage />
    </FormItem>
  )}
/>

Clearly, there’s too much boilerplate around a simple <Input /> intended to control a form field. Leveraging one of React’s greatest features—component composition—we can create a new component that encapsulates this markup, yielding a compact, customizable component.

Creating a Reusable Input Component

// src/components/form/input-default.tsx
import {
  FormControl,
  FormDescription,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from "@/components/ui/form";
import { Input } from "@/components/ui/input";

interface InputDefaultProps {
  control: any;
  name: string;
  label?: string;
  placeholder: string;
  type?: string;
  description?: string;
  className?: string;
  inputClassname?: string;
}

export default function InputDefault({
  control,
  name,
  label,
  placeholder,
  type = "text",
  description,
  className,
  inputClassname,
}: InputDefaultProps) {
  return (
    <FormField
      control={control}
      name={name}
      render={({ field }) => (
        <FormItem className={className}>
          {label && <FormLabel>{label}</FormLabel>}
          <FormControl>
            <Input
              className={inputClassname}
              type={type}
              placeholder={placeholder}
              {...field}
            />
          </FormControl>
          <FormMessage />
          {description && <FormDescription>{description}</FormDescription>}
        </FormItem>
      )}
    />
  );
}

In this component, some props (like control and name) are essential, while others (such as label, description, and style properties) are optional to allow for customization. This design lets you pass additional props—such as onChange events or disabled states—while keeping the component call simple. For example:

// inside a form tag
<InputDefault
  control={form.control}
  name="username"
  label="Username"
  placeholder="Enter your username"
/>

In my projects, I created a form folder inside the components directory to store these pre-styled form components. For each new component—checkbox, select, date picker, text area, etc.—I create a separate file.

Customizing a Select Component

Some components require a bit more complexity. For example, a select component:

import {
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from "@/components/ui/form";
import {
  Select,
  SelectContent,
  SelectItem,
  SelectTrigger,
  SelectValue,
} from "@/components/ui/select";
import { cn } from "@/lib/utils";

interface SelectDefaultProps {
  control: any;
  name: string;
  title?: string;
  label: string;
  className?: string;
  values: {
    value: any;
    label: any;
  }[];
}

export default function SelectDefault({
  control,
  name,
  title,
  label,
  values,
  className,
}: SelectDefaultProps) {
  return (
    <FormField
      control={control}
      name={name}
      render={({ field }) => (
        <FormItem className={cn("flex flex-col", className)}>
          <FormLabel>{title}</FormLabel>
          <Select onValueChange={field.onChange} defaultValue={field.value}>
            <FormControl>
              <SelectTrigger className="hover:bg-accent outline-none data-[placeholder]:text-muted-foreground hover:text-accent-foreground">
                <SelectValue placeholder={label} />
              </SelectTrigger>
            </FormControl>
            <SelectContent>
              {values.map((item, index) => (
                <SelectItem key={index} value={item.value}>
                  {item.label}
                </SelectItem>
              ))}
            </SelectContent>
          </Select>
          <FormMessage />
        </FormItem>
      )}
    />
  );
}

Because we can’t predict how the select items will be arranged, this component is designed to be generic. It accepts an array called values—each with a value and a label—and maps over it to generate the select items. Consequently, the data may need to be formatted before being passed to the component. For example:

const userTypeOptions = userTypes.map((userType) => ({
  label: userType.type,
  value: userType.id,
}));

Then use the component as follows:

<SelectDefault
  control={form.control}
  name="user_type_id"
  label="User type"
  title="Select the user type"
  values={userTypeOptions}
/>

Even with this added complexity, this approach is much better than embedding all the select component tags directly in your form code.

With these organized components and forms, your application will not only look better but will also be much easier to maintain. Let me know in the comments if you implement something similar—or even better—and share your thoughts on improving code organization with this stack.

🔎 From Concept to Schema: How I Design Databases

Micael Miranda Inácio — Mon, 10 Mar 2025 00:11:28 +0000

There are many different ways to design databases, but with some practice, we develop our own approach that seems to work well. In this article, I'll share my process for designing databases. While these methods may need to be adjusted for large-scale projects, in my (not very extensive) experience, the following steps will help you create a functional database model.

📝 Step 0: Defining System Requirements

It's crucial to have a clear understanding of how the software should work, with every functionality defined before properly creating your database. This process will prevent mistakes such as missing tables or fields or incorrectly relating tables. One of the first things we learn in software engineering is requirement analysis—the process of gathering, defining, and validating the needs and constraints of a software system to ensure it meets user expectations and business goals.

You can simply list the functionalities if they are clear in your mind, but if they are still vague, designing a prototype can help a lot. With a visual model of your prototype, you can identify requirements that weren't included in your initial list.

📂 Step 1: Defining the Database Tables

With your requirements carefully defined, it won't be hard to identify the necessary tables. In this step, you'll need to think ahead about the relationships between tables. This will help you identify secondary tables and even "connector tables" (used in many-to-many relationships). Make a list of all the tables and proceed to the next step.

📊 Step 2: Creating the Entity-Relationship Diagram (ERD)

There are many tools available for creating ERDs. Here, I'm using a free one called DB Designer. After choosing your tool, create all the tables and start defining the table fields.

🔑 2.1 - Primary Keys

All tables must have a primary key (ID), which can be defined as a string (UUID or other unique identifier method) or integer (auto-increment). Each approach has its pros and cons, so you need to analyze what is more important for your case:

Use UUID for more security.
Use integer for more speed and simplicity.

Note: The same database can use different ID methods for different tables.

📌 2.2 - Normal Data Fields

Implement all the necessary fields in the tables and define their types and sizes.

Tip: Some commonly used attributes in databases include:

created_at (datetime): Automatically stores the date and time of record creation.
updated_at (datetime): Stores the last modification timestamp.
status (boolean): Used to determine whether the data is active/inactive, resolved/unresolved, etc.

🔗 2.3 - Foreign Keys (Relationships)

To establish relationships between tables, create foreign keys and associate them with the corresponding primary keys. Understanding the type of relationship between tables is crucial to defining these keys correctly:

One-to-One: Consider merging the two tables if appropriate.
One-to-Many / Many-to-One: Indicates which table references the other.
Many-to-Many: Requires a connector table to manage the relationship.

🏷️ 2.4 - Standardizing Naming Conventions

Maintaining a consistent naming convention in your database makes it easier to remember and maintain. Here are some best practices:

Use lowercase for all names.
Use snake_case (_ instead of spaces).
Use plural names for tables.
Name primary keys as id.
Name foreign keys as table_name_id.

🔍 2.5 - Reviewing the Results

Here's an example of a database model after applying these steps:

With this visual model, review the requirements and check if everything looks correct.

Note: In this example, two different ID types were used: varchar (UUID) and integer (auto-increment).

🏗️ Step 3: Generating the Database

DB Designer automatically generates an SQL script that can be used to create your database. Since we have AI tools to make our work easier, I copied the "Markup code" from the modeling tool and asked ChatGPT to generate a database script based on it.

The following is an example of a database script written for Prisma ORM:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id         String   @id @default(uuid())
  name       String
  username   String   @unique
  email      String   @unique
  password   String
  bio        String?
  createdAt  DateTime @default(now()) @map("created_at")
  userTypeId String   @map("user_type_id")
  userType   UserType @relation(fields: [userTypeId], references: [id])

  articles  Article[]
  comments  Comment[]
  feedbacks Feedback[]

  @@map("users")
}

model UserType {
  id    String @id @default(uuid())
  type  String
  users User[]

  @@map("user_types")
}

model Tag {
  id       Int          @id @default(autoincrement())
  name     String       @unique
  articles ArticleTag[]

  @@map("tags")
}

model Article {
  id        String   @id @default(uuid())
  title     String
  imageUrl  String   @map("image_url")
  content   String
  status    Boolean  @default(true)
  createdAt DateTime @default(now()) @map("created_at")
  userId    String   @map("user_id")
  author    User     @relation(fields: [userId], references: [id])

  tags     ArticleTag[]
  comments Comment[]

  @@map("articles")
}

model ArticleTag {
  id        Int    @id @default(autoincrement())
  articleId String @map("article_id")
  tagId     Int    @map("tag_id")

  article Article @relation(fields: [articleId], references: [id])
  tag     Tag     @relation(fields: [tagId], references: [id])

  @@unique([articleId, tagId])
  @@map("article_tags")
}

model Comment {
  id        String   @id @default(uuid())
  content   String
  createdAt DateTime @default(now()) @map("created_at")
  userId    String   @map("user_id")
  articleId String   @map("article_id")

  author  User    @relation(fields: [userId], references: [id])
  article Article @relation(fields: [articleId], references: [id])

  @@map("comments")
}

model Feedback {
  id        String   @id @default(uuid())
  title     String
  message   String
  createdAt DateTime @default(now()) @map("created_at")
  userId    String   @map("user_id")

  user User @relation(fields: [userId], references: [id])

  @@map("feedbacks")
}

model EmailList {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  createdAt DateTime @default(now()) @map("created_at")
  status    Boolean

  @@map("email_list")
}

Notes:

I asked GPT to use the @map and @@map decorators to rename tables and fields following the snake_case convention in database generation.

For string IDs, the default was UUID. For integer IDs, the default was auto-increment.

After reviewing everything, you can generate your database!

🎯 Conclusion

Now we have a fully designed database, built using these simple steps! This method can be a great way to structure your database in many cases, especially for small projects. In your next project, consider these steps and share how you design your databases!

🔐 How to create an authentication system with JWT in a Node.js API

Micael Miranda Inácio — Fri, 07 Mar 2025 20:39:19 +0000

A crucial part of almost every system is a secure authentication mechanism. In this post, we'll implement authentication in a Node.js API built with Fastify. The creation of the API and the first routes related to the user table have already been covered in my previous posts — Check it out here. The base code is available in this GitHub repository: Blog - by micaelmi.

Creating a Login Route

To start the authentication process, we need to create a login route where the user will obtain an access token to use in protected routes. Inside src/routes/users, create login.ts:

import bcrypt from "bcrypt";
import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import jwt from "jsonwebtoken";
import z from "zod";
import { env } from "../../env";
import { ClientError } from "../../errors/client-error";
import { prisma } from "../../lib/prisma";

export async function login(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().post(
    "/users/login",
    {
      schema: {
        summary: "User Login",
        tags: ["users"],
        body: z.object({
          credential: z.string().min(4), // username or email
          password: z.string().min(8).max(32),
        }),
      },
    },
    async (request, reply) => {
      const { credential, password } = request.body;

      const user = await prisma.user.findFirst({
        where: {
          OR: [{ username: credential }, { email: credential }],
        },
      });

      if (!user) throw new ClientError("User does not exist");

      const passwordMatch = await bcrypt.compare(password, user.password);

      if (!passwordMatch) throw new ClientError("Password does not match");

      const secretJwtKey = env.JWT_SECRET_KEY;
      const expirationTime = "30d";

      const token = jwt.sign(
        {
          sub: user.id,
          name: user.name,
          username: user.username,
          type: user.userTypeId,
        },
        secretJwtKey,
        { expiresIn: expirationTime }
      );

      return reply.send({ token });
    }
  );
}

Explanation:

Search for a user in the database using the provided username or email.
Compare the provided password with the stored hashed password using bcrypt.
Create a JWT token containing relevant user data from the database.
Send the generated token back to the user.

Now, register the route in server.ts:

app.register(login);

Test it in Swagger UI. The expected response should look like this:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

You can inspect the token's payload on the JWT Website.

Creating a Middleware to Verify Token Validity

Now we need to create a middleware — a function that runs between the request and response cycle, processing requests before they reach the final handler. This middleware ensures that only authenticated users can access protected routes.


import { FastifyRequest, FastifyReply } from "fastify";
import jwt, { JwtPayload } from "jsonwebtoken";
import { env } from "../env";

const secretKey = env.JWT_SECRET_KEY;

export const verifyToken = async (
  request: FastifyRequest,
  reply: FastifyReply
) => {
  try {
    const authorizationHeader = request.headers.authorization;
    if (!authorizationHeader) {
      return reply.status(401).send({ error: "Token not provided" });
    }

    const token = authorizationHeader.split(" ")[1];
    const decoded = jwt.verify(token, secretKey);

    if (typeof decoded === "string") {
      return reply.status(401).send({ error: "Invalid token" });
    }

    request.user = decoded as JwtPayload & {
      sub: string;
      name: string;
      username: string;
      type: string;
      iat: number;
      exp: number;
    };
  } catch (err: any) {
    console.error("Error on token validation:", err.message);
    return reply.status(401).send({ error: "Invalid token" });
  }
};

This function:

Ensures a token is provided.
Verifies the token's validity.
Stores the decoded user data in request.user for later use.

Applying the Middleware and Testing Route Protection

To enforce authentication, add a preHandler hook in server.ts:

app.register(async (app) => {
  app.addHook("preHandler", verifyToken);
  // Protected routes go here
});

Now, test a protected route without a token. The response should be:

{
  "error": "Token not provided"
}

To enable token authentication in Swagger UI, update fastifySwagger configuration, adding the following code right after the info object:

//...
info: {
  title: "Blog API",
  description: "API for my blog project.",
  version: "1.0.0",
}, // ⬇️⬇️⬇️
securityDefinitions: {
  BearerAuth: {
    type: "apiKey",
    name: "Authorization",
    in: "header",
    description: "Enter your JWT token in the format: Bearer <token>",
  },
},
security: [{ BearerAuth: [] }],
// ...

A new "Authorize" button will appear. Click it and enter your token in the following format:

Bearer <your-token>

Note: Don't forget to include "Bearer" before the token.

After authorization, protected routes will be accessible.

Conclusion

Now we have a simple but effective authentication system that allows public and protected routes in the API. If anything seems off, check out the project repository: Blog - by micaelmi.

Further improvements could include role-based access control (RBAC) to set different permissions for different users or another user-type validation process. But for now, we have a fully functional authentication system.

🛠️ How to Build Routes in a Node.js API with Fastify and Prisma

Micael Miranda Inácio — Tue, 04 Mar 2025 19:42:19 +0000

Continuing from the previous post 🚀 How to Set Up a Node.js API with Fastify and Prisma, let's now code our first route.

Setting Up the Prisma Client

First, we need to create a Prisma client that will be used to interact with our database. Inside the /src/lib directory, create a file named prisma.ts and add the following code:

import { PrismaClient } from "@prisma/client";

export const prisma = new PrismaClient();

Organizing Routes

Next, create a folder named routes inside /src. Within /routes, create another folder named users, where we'll store all user-related functions.

Our first file inside this folder will be create.ts. The required imports for this file are:

import bcrypt from "bcrypt";
import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import z from "zod";
import { prisma } from "../../lib/prisma"; // our newly defined client

Apart from bcrypt, all our routes will import these core libraries from Fastify, Zod and Prisma.

Defining the Route

The function definition includes the HTTP route path, some documentation details, and a Zod-typed schema for input validation. Here’s how it looks:

export async function createAccount(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().post(
    "/users",
    {
      schema: {
        summary: "Create account",
        tags: ["users"],
        body: z.object({
          name: z.string(),
          username: z.string().min(4),
          email: z.string().email(),
          password: z.string().min(8).max(32),
          bio: z.string().optional(),
        }),
      },
    },
    async (request, reply) => {
      // The next part will be placed here
    }
  );
}

Zod provides powerful tools for defining validation rules, ensuring our API only accepts correctly formatted data.

Implementing the Route Logic

Inside the function, we need to retrieve the request data, hash the password, and store the user in the database:

const { name, username, email, password, bio } = request.body;

const hashedPassword = await bcrypt.hash(password, 10);
const user = await prisma.user.create({
  data: {
    name,
    username,
    email,
    password: hashedPassword,
    bio,
  },
});

return reply.status(201).send({ userId: user.id });

Registering the Route in the Server

Now that our route is created, we need to import it into server.ts so it can be used.

At the beginning of the server.ts file, add:

import { createAccount } from "./routes/users/create";

Then, register the route before the app.listen call:

app.register(createAccount);

Now, reload the Swagger page and the route should be automatically indexed. Besides the documentation, you can also test your route by clicking on the "Try out" button and editing the body. If you followed the steps correctly, your route should be working!

Building the Route to List Users

To list all registered users, create a new file named list.ts inside the /src/routes/users folder and add the following code:

import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import { prisma } from "../../lib/prisma";

export async function listAllUsers(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().get(
    "/users",
    {
      schema: {
        summary: "List all the registered users",
        tags: ["users"],
      },
    },
    async (request, reply) => {
      const users = await prisma.user.findMany({
        select: {
          id: true,
          name: true,
          username: true,
          email: true,
          bio: true,
          createdAt: true,
        },
      });
      return reply.send({ users });
    }
  );
}

Note:

The schema here is similar to the one for creating an account, but simpler. We use Prisma’s findMany() method with the select option to retrieve only specific fields from the database. You can adjust this to filter or format data as needed.

Updating a User

Next, create a file named update.ts in the same folder (/src/routes/users) with the following code:

import bcrypt from "bcrypt";
import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import z from "zod";
import { prisma } from "../../lib/prisma";

export async function updateUser(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().put(
    "/users/:userId",
    {
      schema: {
        summary: "Update user",
        tags: ["users"],
        params: z.object({
          userId: z.string().uuid(),
        }),
        body: z.object({
          name: z.string().optional(),
          username: z.string().min(4).optional(),
          email: z.string().email().optional(),
          password: z.string().min(8).max(32).optional(),
          bio: z.string().optional(),
        }),
      },
    },
    async (request, reply) => {
      const { userId } = request.params;
      let { password } = request.body;

      if (password) {
        password = await bcrypt.hash(password, 10);
      }
      const user = await prisma.user.update({
        where: { id: userId },
        data: {
          ...request.body,
          password, // will be undefined if not provided
        },
      });

      return reply.status(200).send({ userId: user.id });
    }
  );
}

Key Points:

HTTP Method & URL Params: We use the PUT method and include a URL parameter (:userId), which is validated by Zod in the params schema.
Optional Fields: All fields in the body are optional since the user might update only a subset of the fields.
Password Encryption: If a new password is provided, it is hashed before updating the record.
Spread Operator: The spread operator (...request.body) is used to pass all the fields, with the exception of password which is handled separately.

Deleting a User

Finally, to complete the CRUD operations, create a file named delete.ts in the /src/routes/users folder with the following code:

import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import { prisma } from "../../lib/prisma";
import z from "zod";

export async function deleteUser(app: FastifyInstance) {
  app.withTypeProvider<ZodTypeProvider>().delete(
    "/users/:userId",
    {
      schema: {
        summary: "Delete user by id",
        tags: ["users"],
        params: z.object({
          userId: z.string().uuid(),
        }),
      },
    },
    async (request, reply) => {
      const { userId } = request.params;
      const user = await prisma.user.delete({
        where: { id: userId },
      });

      return reply.send({ user });
    }
  );
}

Note:

This route follows the same pattern as the others—the only difference being the HTTP DELETE method. Register it in your server and test it on Swagger.

Improving the Imports with a Route Index File

As your server.ts file grows, importing every route individually can make it look messy. To improve organization, create an index.ts file inside the /src/routes/users folder:

import type { FastifyInstance } from "fastify";
import { ZodTypeProvider } from "fastify-type-provider-zod";
import { createAccount } from "./create";
import { listAllUsers } from "./list";
import { updateUser } from "./update";
import { deleteUser } from "./delete";

export async function userRoutes(app: FastifyInstance) {
  const typedApp = app.withTypeProvider<ZodTypeProvider>();
  typedApp.register(createAccount);
  typedApp.register(listAllUsers);
  typedApp.register(updateUser);
  typedApp.register(deleteUser);
}

Now, in your server.ts, instead of registering each route separately, import and register the consolidated userRoutes function:

import { userRoutes } from "./routes/users";

app.register(userRoutes);

This setup helps keep your code organized and your server.ts file clean.

With all these routes in place and registered, your API now supports creating, listing, updating, and deleting users. Test all the routes via the Swagger UI at http://localhost:3333/docs.

Conclusion

Now we have implemented the most important features, covering the CRUD functions and some best practices. However, there are many possible improvements that can be made in upcoming versions. Follow the updates here and in the project repository: GitHub - micaelmi/blog.Next step is to implement authentication and route protection, stay tuned!

🚀 How to set up a Node.js API with Fastify and Prisma

Micael Miranda Inácio — Mon, 24 Feb 2025 22:18:14 +0000

Building APIs with Node.js has never been more exciting—especially when you use a modern stack that emphasizes speed, type safety, and developer experience. In this post, I want to share my journey of setting up a Node API using Fastify for its blazing performance, Prisma for type-safe database access, and some other key tools that round out the experience.

What I’m Using

Here’s a quick rundown of the main tools and libraries that power my project:

pnpm – My package manager of choice for efficient dependency handling.
Fastify – A lightweight and fast Node.js web framework.
Prisma – An ORM that not only makes querying databases type-safe but also improves productivity.
Swagger – To generate interactive API documentation.
Zod – For runtime validation and to assist with documentation via type definitions.
Docker – I use Docker to containerize the API (and even the Postgres database) so that my local environment remains clean and consistent.

Getting Started with the Project

To start your project, follow these steps:

Initialize the Project The first thing to do is to create the project main folder, which I named blog, and inside it, create another folder named backend. After creating this folders, inside the backend folder, let's initialize the Node.js project using the pnpm init command.

pnpm init

This will generate a package.json file. You can then proceed to install the necessary dependencies.

If you don't have pnpm on your computer, follow the installation guide in this link: pnpm installation.

Install Dependencies

Run the following command to install the normal dependencies (libraries needed for the runtime):

pnpm add @fastify/cors @fastify/jwt @fastify/swagger @fastify/swagger-ui @prisma/client bcrypt dotenv fastify fastify-type-provider-zod helmet jsonwebtoken swagger-themes zod

To install the development dependencies (libraries needed for development, testing, etc.), run:

pnpm add -D @types/bcrypt @types/jsonwebtoken @types/node prisma ts-node tsup tsx typescript

Dependency Breakdown

Normal Dependencies

@fastify/cors

A Fastify plugin to enable Cross-Origin Resource Sharing (CORS) for your API. This allows your server to respond to requests from different origins, which is essential for enabling client-side applications (on different domains) to communicate with your server.
@fastify/jwt

A Fastify plugin that provides JSON Web Token (JWT) support for authentication. It helps you create and verify JWTs, enabling secure token-based authentication in your API.
@fastify/swagger

A Fastify plugin to integrate Swagger, which is a tool for API documentation. It automatically generates and serves a Swagger UI to explore and interact with your API endpoints.
@fastify/swagger-ui

This plugin provides a UI for the Swagger documentation, enabling you to visualize and test your API endpoints directly from the browser.
@prisma/client

Prisma Client is an auto-generated query builder used to interact with your database. It provides a type-safe and easy-to-use API for querying and manipulating your database records.
bcrypt

A library to hash passwords securely. It helps to store user passwords in a safe, hashed format, preventing them from being exposed if the database is compromised.
dotenv

A library that loads environment variables from a .env file into process.env. This is useful for storing sensitive configuration settings, like database credentials, API keys, or other environment-specific variables.
fastify

The core framework that powers your API. Fastify is a fast and low-overhead web framework designed for building APIs with minimal performance impact.
fastify-type-provider-zod

A Fastify plugin that integrates Zod (a TypeScript-first schema declaration and validation library) with Fastify, enabling you to enforce type safety in your route schemas and validations.
helmet

Helmet is a security middleware that helps secure your API by setting HTTP headers like Content Security Policy (CSP), X-Content-Type-Options, and others, which protect your app from some known web vulnerabilities.
jsonwebtoken

A library to create and verify JWTs. It's used for handling the creation and verification of tokens, which are typically used for authentication and session management.
swagger-themes

A library that provides customizable themes for the Swagger UI, giving you flexibility to style the API documentation to match your brand or personal preferences.
zod

A TypeScript-first schema validation library used for defining and validating data structures. It provides type safety for the input/output data of your API and integrates with Fastify via fastify-type-provider-zod.

Development Dependencies

@types/bcrypt

Provides TypeScript definitions for the bcrypt library, allowing TypeScript to understand the types used in the bcrypt library and provide type safety when using it.
@types/jsonwebtoken

Provides TypeScript definitions for the jsonwebtoken library, helping TypeScript understand its types and provide accurate type-checking for JWT operations.
@types/node

Provides TypeScript definitions for Node.js core modules like fs, path, http, and others. This ensures TypeScript understands the native Node.js APIs and offers type safety when interacting with them.
prisma

The Prisma CLI used for generating Prisma client, running database migrations, and managing your database schema. It helps to automate the setup of your database models and query the database.
ts-node

A TypeScript execution environment for Node.js. It allows you to run TypeScript files directly without needing to compile them manually. Great for development and testing.
tsup

A fast TypeScript bundler that compiles your code into a production-ready bundle. It's used here to bundle your TypeScript code before running it in production.
tsx

A tool that runs TypeScript files directly in Node.js without needing a compilation step. It's used here to run your TypeScript files in development mode.
typescript

The TypeScript language itself, enabling static typing and compilation from TypeScript to JavaScript, which improves developer productivity and code safety.

Each of these dependencies plays a critical role in making your Node.js API project fast, secure, type-safe, and easy to maintain. They help with everything from security (Helmet), to database interaction (Prisma), to development workflows (pnpm, TypeScript, and Prisma CLI), ensuring that you can scale and maintain your project efficiently. They will be used in the next steps.

Setting Up the Database with Docker

Now that we've set up our project, it's time to create our database using Docker. In the root directory of your project ("/blog"), create a docker-compose.yaml file and paste the following configuration:

version: "3.8"

services:
  blog-postgres-db:
    profiles: [dev, prod]
    image: bitnami/postgresql:14 
    container_name: blog-postgres-db
    ports:
      - "5432:5432"  # Expose PostgreSQL port for development (remove in production)
    restart: unless-stopped
    environment:
      - POSTGRES_USER=${DATABASE_USERNAME:-docker}
      - POSTGRES_PASSWORD=${DATABASE_PASSWORD:-docker}
      - POSTGRES_DB=${DATABASE_NAME:-blog}
    volumes:
      - blog_db_volume:/bitnami/postgresql  # Persist database data in a Docker volume
    networks:
      - blog-network
    env_file:
      - .env  # Load environment variables from the .env file

volumes:
  blog_db_volume:
    driver: local  # Specify the volume driver for local persistence

networks:
  blog-network:
    driver: bridge  # Use the bridge network for service communication

Environment Variables

Next, create a .env file in the root directory to securely store your environment variables. This file will be used to configure the PostgreSQL database.

DATABASE_USERNAME=docker
DATABASE_PASSWORD=docker
DATABASE_NAME=blog

Running the Database with Docker

To spin up the database in development mode, run the following command:

docker compose --profile dev up -d

This will start the PostgreSQL container in the background, creating the database as defined in your .env file.

Notes:

Environment Variables: We are using the env_file directive to load the environment variables from the .env file into the Docker container, making it easier to manage sensitive data securely.
Docker Image Versioning: Instead of using the latest tag for the PostgreSQL image, it's recommended to pin the version (e.g., bitnami/postgresql:14) to ensure compatibility and prevent unexpected issues from future image updates.
Security in Production: In production, you may want to remove the ports configuration to avoid exposing your database to the internet. It's also a good idea to restrict database access to only your API services using Docker networks.

This setup ensures a smooth transition from development to production, making it easier to manage the database and environment configuration securely.

Configuring Prisma

With the database set up, it's time to configure Prisma ORM, define our schema, and establish a connection to the database container.

1. Initialize Prisma

Run the following command to initialize Prisma in your project:

pnpm prisma init

This command creates a folder named prisma, along with a schema.prisma file inside it. Additionally, a .env file will be generated containing the database connection URL.

Update the .env file with the correct connection string:

DATABASE_URL="postgresql://docker:docker@localhost:5432/blog"

Now, Prisma should be able to connect to the database.

2. Define Database Models

Inside the schema.prisma file, we can define the models that represent our database tables. Below is an example of a User model:

model User {
  id         String   @id @default(uuid())
  name       String
  username   String   @unique
  email      String   @unique
  password   String
  bio        String?
  createdAt  DateTime @default(now()) @map("created_at")

  @@map("users")
}

In an upcoming chapter, I'll explain my database design process in more detail.

3. Run the First Migration

With our first schema created, we can now run the following command to apply the changes to the database:

npx prisma migrate dev

This command creates a migration file containing the SQL statements needed to set up the database schema. You will be prompted to name the migration—I called mine "first migration", but you can choose any name that makes sense for your project.

Each migration is an incremental step that modifies the database structure while preserving data. Prisma tracks all migrations in a dedicated folder.

⚠️ Important:

Never delete a migration file unless you intend to reset and recreate the entire database, as this could lead to data loss.

Coding `server.ts`

The src/server.ts file is the core of our API, as it imports and initializes all essential functionalities.

1. Setting Up the Fastify App

First, we need to instantiate the Fastify app and define a listen function so that our API becomes accessible on a specified port:

import fastify from "fastify";

export const app = fastify();

app.listen({ port: env.PORT, host: "0.0.0.0" }).then(() => {
  console.log("Server running on port " + env.PORT);
});

The env.PORT value should be set in the same .env file we created while configuring Prisma. Add the following line:

PORT=3333

However, instead of directly importing environment variables from .env, we can use TypeScript with Zod to create a strongly typed and validated configuration model.

2. Creating an `env.ts` Configuration File

Inside the /src folder, create a new file called env.ts, and define the environment variables as follows:

import { z } from "zod";
import { config } from "dotenv";

if (process.env.NODE_ENV === "test") {
  config({ path: ".env.test", override: true });
} else {
  config();
}

export const envSchema = z.object({
  NODE_ENV: z.enum(["development", "test", "production"]).default("development"),
  DATABASE_URL: z.string().url().min(1),
  PORT: z.coerce.number().default(3333),
});

export const env = envSchema.parse(process.env);

This ensures that:

All required environment variables are present.
The PORT is always treated as a number.
The DATABASE_URL follows a valid URL format.
A default value is set for NODE_ENV.

Now, import env.ts inside server.ts:

import { env } from "./env";

This will eliminate potential errors related to missing or invalid environment variables.

Adding Important Plugins

Below the app definition, we can register essential plugins, such as CORS and Swagger (with Zod integration) for API documentation:

import cors from "@fastify/cors";
import fastifySwagger from "@fastify/swagger";
import fastifySwaggerUI from "@fastify/swagger-ui";
import fastify from "fastify";
import {
  jsonSchemaTransform,
  serializerCompiler,
  validatorCompiler,
} from "fastify-type-provider-zod";
import { env } from "./env";
import { SwaggerTheme, SwaggerThemeNameEnum } from "swagger-themes";

export const app = fastify();

const theme = new SwaggerTheme();
const content = theme.getBuffer(SwaggerThemeNameEnum.DARK); // Dark mode for Swagger UI

// Enable CORS to allow external connections to the API
app.register(cors, {
  origin: "*",
});

// Swagger documentation setup
app.register(fastifySwagger, {
  swagger: {
    consumes: ["application/json"],
    produces: ["application/json"],
    info: {
      title: "Blog API",
      description: "API for my blog project.",
      version: "1.0.0",
    },
  },
});

app.register(fastifySwaggerUI, {
  routePrefix: "/docs",
  theme: {
    css: [{ filename: "theme.css", content: content }],
  },
});

app.setValidatorCompiler(validatorCompiler);
app.setSerializerCompiler(serializerCompiler);

// here's where our routes will be imported

app.listen({ port: env.PORT, host: "0.0.0.0" }).then(() => {
  console.log("Server running on port " + env.PORT);
});

Now, when your API is running, you can access the documentation at:

🔗 http://localhost:3333/docs

But to run the API, you need to follow the next step:

3. Setting Up Scripts in `package.json`

To easily manage and run our API, we define terminal commands inside the scripts section of package.json:

"scripts": {
  "dev": "tsx watch src/server.ts",
  "build": "tsup src",
  "start": "node dist/server.js",
  "studio": "npx prisma studio",
  "migrate": "npx prisma migrate dev",
  "database:up": "docker compose --profile dev up -d",
  "database:stop": "docker compose --profile dev stop",
  "database:down": "docker compose --profile dev down"
}

Running the API

With everything configured, start the API by running:

pnpm dev

If everything is set up correctly, you should see the following message in the terminal:

Server running on port 3333

Now, try opening http://localhost:3333/docs in your browser to view the Swagger documentation.

⏭️ Next Steps

In the next post, we will implement error handling, create our first routes and implement authentication using JWT.
Wait for it! See you soon 👋