Moving from local tools to network services. Let's talk about the architecture and challenges of building a professional Feedback API.
In my last posts, I shared the journey of building a CLI tool with a focus on simple architecture and automated testing. It was a success in terms of local automation.
But in the real world, software often needs to live on the network. It needs to be available for multiple users, persist data in a database, and handle concurrent requests.
That’s why my next project is a Minimalist Feedback API.
Here is why I’m building it and the "Senior-level" architectural choices I’m making.
The Use Case: A Universal Feedback Bridge
Many developers build beautiful static portfolios (using Astro, Next.js, or Hugo). But when it comes to adding a "Contact Me" or "Feedback" form, they hit a wall. They usually end up using a third-party paid service or a complex backend.
I’m building a lightweight, professional service that any static site can "talk to" to store messages and feedbacks.
The Architectural Shift: Clean Thinking
For this API, I’m not just throwing everything into a single server.js file. I’m introducing a simplified version of Clean Architecture.
1. Domain First, Framework Second
The "Business Logic" (what defines a valid feedback) should not depend on whether I'm using Express, Fastify, or even if I'm saving to MongoDB or PostgreSQL. The heart of the application will be isolated.
2. Validation as a First-Class Citizen
In a CLI, you control the input. In an API, the world is a chaotic place. I’ll be using Zod to ensure that only "clean" data enters my system. No validation, no entry.
3. Dependency Injection
I want to be able to test my logic without actually hitting a real database. By using Dependency Injection, I can swap a "Real Repository" for a "Mock Repository" in my tests instantly.
The Tech Stack for 2024/2025
To keep it modern and fast, I’ve chosen:
- Node.js (Runtime)
- Fastify: Faster and more modern than Express, with great TypeScript support.
- SQLite + Prisma: For easy setup and type-safe database queries.
- Jest: Because a professional API without tests is just a disaster waiting to happen.
What to Expect in the Next Posts
I’ll be documenting the Step-by-Step construction of this API.
- Part 1: Designing the Domain and Entities.
- Part 2: Setting up the HTTP Layer with Fastify.
- Part 3: Database Integration and Migrations.
- Part 4: Deploying with Docker/Cloud.
The goal isn't just to show you "how to code an API," but how to engineer a service that you’d be proud to show in a technical interview.
When you build an API, what is your biggest challenge? Authentication, Database design, or Deployment? Let's talk in the comments!
Top comments (0)