Let the browser console create the files
At first, the browser console was only a debugging tool.
I wrote the same create, read, update, and delete code several times. The console already knew about controllers, services, tables, and SQL query names. So I added code generation.
The basic flow is simple:
- SQL → New SQL file: choose a table and create named queries.
- Service → New service: connect service methods to the queries.
- Controller → New controller: choose the service and create the routes.
Before it creates the file, the controller screen shows every route. It also shows the linked service method and SQL query.
The New controller screen shows five routes and how each route connects to a service method and an SQL query.
After I save the controller, the route is ready without restarting the backend.
The console is optional. I can still create files in an editor and place them in workspace/controller, workspace/service, or workspace/sql.
When the server is running, the console finds these files and shows a Load button. This extra click is safer than loading a file while I am still editing it.
Test the API right away
After I create a controller, I can call it from the built-in API tester.
GET /api/snack returns 200 OK and three test rows without restarting the backend.
My work cycle is now short:
SQL → service → controller → test → edit → test again
A restart may take only a few seconds, but it can still break my focus. Removing that step makes it easier to try a change and check the result immediately.
See each step of a request
A single number such as “7 ms” does not tell me what happened inside a request.
I wanted to see:
- which route received the request,
- which controller and service ran,
- which SQL query ran,
- how many rows came back,
- and how long each step took.
The Request Trace screen shows these steps in order. In this local example, GET /api/snack finished in 7 ms. One SQL query took 1 ms and returned three rows.
The trace shows the route, controller, SQL query, service method, row count, status, and time for one request.
The 7 ms result is not a speed test. It is only a small request on a local computer. The important part is the list of steps.
When a request is slow or fails, I can see where to start looking.
The console also records request IDs and user activity. In hospital software, it can be important to know who opened data and what happened after that.
Build a Vue 3 screen
After the backend structure worked, I asked another question. Could the same information also create a useful starting screen?
The Screen Designer lets me build a basic data screen for creating, viewing, editing, and deleting records. I can preview it in desktop, tablet, and mobile sizes, and then export a Vue 3 project.
The Screen Designer previews a snack list and can export normal Vue 3 source code.
The exported project is normal source code. A team can open it, change it, and continue development outside the designer. The final application does not have to stay inside aidot-express.
Work without internet access
Some hospital networks are isolated or have strict network rules. The project must still work in those environments.
- The user-interface files are stored and served locally. The app does not need a CDN when it runs.
- The framework and browser console can run inside a private network.
- On Windows, the backend can run as a Windows service. An Electron desktop app can connect to it as a viewer.
The public GitHub repository includes the framework, browser console, API tester, request tracing, and Screen Designer described in this article.
High availability, backup and restore, column encryption, and hospital-middleware integration are separate Enterprise features.
Three lessons I learned
1. Clear rules save repeated decisions.
A small API does not need every feature of a large framework. However, it still helps to have fixed places for controllers, services, and SQL.
2. A code generator should create normal source code.
The files created by the browser console can be opened, reviewed, stored in Git, and edited by hand. Generated files and hand-written files work in the same way.
3. A fast work cycle is more useful than many templates.
Creating five basic routes is helpful. But the bigger benefit is being able to create, load, call, check, and change an endpoint without losing focus.
When to use it
aidot-express can be a good fit for:
- internal REST APIs and admin tools,
- teams that like separate Controller and Service layers,
- projects where developers or database administrators need to read the SQL directly,
- systems that run inside a company or hospital network,
- and small teams that manage the whole application.
It is not designed to be:
- a platform for managing many microservices,
- a framework that hides all database work behind an ORM,
- or the best choice for every Node.js project.
PostgreSQL is not supported yet. The open-source repository is available under the Apache License 2.0.
Try it
For the easiest setup, I recommend Node.js 22 or newer and MariaDB or MySQL.
git clone https://github.com/mike-jung/aidot-express.git
cd aidot-express
npm install
cp .env.example .env # add your database settings
npm start
On Windows PowerShell, use this command instead of cp:
Copy-Item .env.example .env
Open http://localhost:7901. Sign in with the default administrator account shown in the GitHub README, and change the default password right away.
Then create an SQL file, a service, and a controller. Open API Test and call the new route.
If you build internal tools with Express, I would like to know how much structure you prefer. When does helpful structure start to feel too heavy?
GitHub: https://github.com/mike-jung/aidot-express
I am the creator of aidot-express. The screenshots and code examples in this article come from my project.
