I'm building an internal work-reporting tool with specific requirements and an existing Microsoft Access database that I may migrate or continue using as a source for some of the data. I have experience with JavaScript, HTML, CSS/SCSS/SASS, PHP, and SQL, but I mainly work on this project in my spare time and would appreciate advice on making sensible, efficient technical choices.
I'm intentionally avoiding Angular, React, Vue, and Next.js for now. My current setup has two parts:
- An Express.js API using SQLite and Drizzle ORM. It provides application data, including annual reports.
- A Vite-powered frontend using vanilla JavaScript, with my own templating system and router. Employees use it to record hours by project and customer, while administrators can create reports.
Both services currently run in Docker, and the development workflow is working reasonably well. Live code changes are reflected while the containers are running, although adding new npm packages requires rebuilding the images.
What would you recommend improving before moving this into production? I'd like to keep the application lean and avoid unnecessary dependencies or splitting every component into a separate service. I'm especially unsure about the backend and about whether I should use Vite, another bundler, or a different production setup for the frontend. I'd appreciate practical recommendations for development, testing, logging, deployment, and database choices while staying with a JavaScript-based stack.
3 Answers
If the application is already written in JavaScript, I’d avoid changing backend languages just to chase a simpler deployment. Express can stay quite lean when you keep the structure clear and limit dependencies. Put configuration in environment variables, validate incoming data, use a proper production process, add structured logging, and make sure errors don’t expose sensitive details. A single Docker Compose setup with the API and frontend is completely reasonable for an internal tool; you don’t need microservices unless there’s a real operational reason for them.
SQLite may be entirely adequate here, especially for an internal tool with moderate traffic and a relatively simple workload. The important questions are how many concurrent writes you expect, where the database file and backups live, and whether your deployment uses reliable persistent storage. If you need multiple application instances, frequent concurrent writes, or stronger operational tooling, PostgreSQL would be a sensible migration target. Otherwise, switching databases prematurely may add complexity without solving a current problem.
For development, keep the database and uploaded or generated files on persistent Docker volumes, and use a separate production configuration. Adding a package should normally only require rebuilding the development image; you can make that workflow easier with a bind-mounted source tree and a containerized npm install step.
Your current stack already sounds reasonable. If vanilla JavaScript is meeting your needs, there’s no strong reason to add a framework just because it’s popular. I’d spend the effort on fundamentals that matter in production: request and error logging, automated tests for the API and important business rules, input validation, authentication and authorization, database backups, and a straightforward deployment process.
For the frontend, Vite is a perfectly suitable choice for production. You can use its build command to generate static assets and serve those files from a small web server or from the same Node deployment. You don’t need to switch to Webpack unless you have a specific feature or compatibility requirement that Vite cannot handle.
That’s reassuring. For production, would you simply use Vite’s build output, or would you recommend another bundler? I’ve tried Vite before and had trouble getting a build working in another project, so I’m unsure whether my custom templating and routing code will bundle correctly.
SQLite is still working well for the current scale, so I’ll probably keep it for now while making backups and deployment storage more deliberate. PostgreSQL can remain a future option if the workload or hosting setup requires it.