I'm building an internal work-reporting tool with some specific requirements. There's already an MS Access database, and I may migrate it into the new application while continuing to use many of its tables as data sources.
My background is in JavaScript, HTML, CSS/SCSS/Sass, PHP, and SQL. Since I mainly work on this in my spare time, I'm looking for practical ways to make good decisions about efficiency and maintainability. I'd prefer not to use Angular, React, Vue, or Next.js because they feel unnecessary for this project.
The current setup has two parts:
- An Express.js API using SQLite and Drizzle ORM. It provides the data needed by the frontend, including annual reports.
- A Vite-powered frontend using vanilla JavaScript, with a custom templating system and router. Employees use it to log working hours by project and customer, while administrators have dashboards for creating reports.
Both services currently run in Docker, and the development workflow is working reasonably well. Live code updates work while the containers are running, although adding new npm packages requires rebuilding the images.
I'd like to keep the application and development environment as lean as possible, with minimal dependencies. The frontend already does what I need, but I'm less confident about the backend and how I should prepare everything for production. I'm also happy with starting the whole setup using one Docker command rather than splitting every component into separate services.
What would you improve in this setup? In particular, I'd appreciate advice about the Node.js backend, database choice, production bundling, Docker workflows, logging, testing, and deployment. I'm open to practical improvements, but I don't want to add complexity just for the sake of following popular tools.
3 Answers
SQLite isn’t automatically a bad choice. For a small internal tool with modest concurrency, it can be fast, simple, and easy to back up. The important questions are whether you need multiple application instances writing concurrently, networked database access, advanced reporting queries, or stronger operational features.
If the application grows or you expect several production instances, PostgreSQL would be a sensible next step. I’d avoid migrating purely because it feels more professional; make the decision based on workload, backup requirements, concurrency, and deployment plans.
Exactly. For many internal applications, the database won’t be the limiting factor for a long time. A clean data-access layer makes a later migration much less painful if the need eventually appears.
Your stack already sounds sensible for an internal application. If vanilla JavaScript is working well, there’s no need to add a framework just because it’s common. I’d put more effort into fundamentals: clear API boundaries, validation, error handling, structured logging, automated tests, backups, and a straightforward deployment process.
For production, Vite is a reasonable choice for bundling the frontend. Run its production build command and serve the generated static files from a small web server or from your Node process. You don’t need to switch to Webpack unless you have a specific feature that Vite can’t support.
That’s reassuring. I’ll take another look at Vite’s production build and focus on making sure the source behaves correctly after bundling instead of adding another tool immediately.
Keep the development and production concerns separate. In development, bind-mount the source and use a file-watching Node process so code changes are picked up without rebuilding. Installing a new dependency usually requires rebuilding because the image’s dependency layer changed, which is normal; you can improve the workflow with a dedicated development Dockerfile and a named volume for node_modules.
For production, install only production dependencies, run the frontend’s optimized build, use environment variables for configuration, add health checks, and make sure database backups and migrations are handled explicitly. A single Docker Compose command is perfectly fine for a small deployment. You don’t need to turn every piece into an independently managed service.
PostgreSQL is on my longer-term list, but I’ll measure the actual requirements first rather than replacing SQLite without a concrete reason.