Building Node.js API services should be easy, yet a lot of developers struggle when they need to start a new backend service. Every month there are new ways to set up your Node.js project, new best practices for auth or security, a new framework, or your favourite NPM package has breaking changes since the last time you used it.
Every time I speak with backend devs who work with Node.js, they all say the same thing - setting up your service from scratch is a pain. Most of the time, they don't remember how to configure TypeScript to work with Node.js, how to run in localhost with watch mode enabled, set up their auth flows with JWT access tokens, or get their NGINX web proxy working correctly.
To be honest, I also fall into that category. Whenever I start working on a new Node.js API service, I open one of my older projects and copy most of the basic logic from there. Sometimes I even check multiple projects to find various parts of the puzzle. Then I run pnpm run dev and... I get an error. Something went wrong, and I spend half a day figuring it out.
Recently, I've been quite impressed by the work that shadcn has done with his shadcn/ui library, so I thought, why not build something similar for backend developers?
Introducing Vratix
Vratix is a collection of easy to use Open Source API Modules and Node.js templates that implement common backend logic while following the latest best practices. It’s built to be extensible, robust, and secure. Vratix comes with:
- Fully tested modules with Postman API collections ready to use
- A CLI for quick setup - no more searching for guides or copying code from old projects
- Modular, extensible, and secure architecture
Just like shadcn/ui, you own the source code - we import it into your project, and you retain full control and ownership. Using the Vratix CLI, you can get a Node.js API in a few seconds.
We’re also working on private API Modules so you can build custom logic or modify community modules and reuse them across projects.
We believe that DX is the most important thing when building dev tools, so we have built the CLI with that in mind - no assumptions, as least dependencies as possible and comprehensive documentation. Our docs show the full list of API Modules and what is coming next!
Learn more about how we build our modules in these guides:
Have you experienced these frustrations when building Express.js APIs? What tools or workflows do you rely on when setting up a new project from scratch? Let me know in the comments!
Join our backend community on Discord!
Follow me on X for more of my daily thoughts on tech.
Top comments (7)
I've created some bootstrap projects as a starter for new projects that speeds up the process. However, there are still things to adjust. Great idea with vratix to get on speed with new ideas!
A few of the people I spoke with have done the same thing - they have project templates on GitHub. With Vratix you can have partial logic and our CLI will integrate it into your project, resolve dependencies, imports, migration files etc so it's way more useful than just a boilerplate template.
Lmk if you try Vratix, we are in public beta and are collecting feedback on what we should improve and build next :)
nice
It's a great initiative and it's good, if not perfect, for small projects. But as a project grows large I can't see myself using something like this. This is opinionated and if I am not aware of the things that's going on behind the screen, especially the implementation details, I can't manage the project going ahead, let alone collaborating.
Yes, I am aware I can see and change things. But if I had a choice between analyze and rewrite someone else's code and design and write my own, I would chose the later, unless I'm prototyping. And it is a rare case to prototype a backend app.
Now what made shadcn work was that it looks beautiful along with being what it claims to be. But the same also stands for shadcn that I've to either modify it or do what it says to change it's look and functionality, and tbh I found it to be troublesome because it used Radix UI under the hood and doesn't mention it in the forefront.
This reminds me of the fact that your project is built on top of Express and it's fundamentals. You might want to include that in your home page.
I know my comment is a bit on the negative side but you're going to put in tons of hours in it. So I would suggest looking in to whether the devs really need something like this.
But if you're fine with the opinionated structure then you're good to go. Keeping my negative remarks aside, it's a cool project all in all.
@deathcrafter thats a great feedback, thanks a lot for this. For sure, we are aware of those points and we try to keep them in mind when we build the modules, definitely lots of points to address, we wanna keep it as less opinionated and dependent on other stuff. As you pointed simplifying it will make it easy to use and contribute by others
One of the things we need to document better is the folder structure and some of the main design patterns we use (although they are pretty common).
On the Express bit -> as interest grows we want to add the rest of the Node.js frameworks, make it work for Next.js as well and also support some other languages
NICE
thank you