TypeScript ❤ Node.js: the tale of Stix
For the past few months, I’ve been working on a new framework for Node.js using TypeScript. This has been a lot of fun and a lot of headaches but most of all very satisfying.
I’ve used many frameworks across many languages and found the ones available in Node.js to not quite be what I was looking for. The closest I got was Nest.js but it still wasn’t what I wanted. I wanted more structure and less magic. More separation and fewer headaches. Proved strategies to prevent me from messing up. Design patterns that work.
Stix is for those projects that start small and need to be flexible and scale later on without putting overwhelming weight on your shoulders from the start. You want to get started quickly but you don’t want to spend weeks setting up that perfect directory structure.
It’s for those projects where normally you would pick a cool and simple framework that has a huge initial wow factor so you can get started quickly and build that awesome MVP. You promise yourself and your team that you’ll rewrite it once it has proven itself to be successful, and your manager agrees. If it works, you get to rewrite it and refactor it. You feel reassured. You go ahead and allow yourself to write a couple of lines of dirty code for the promise of a better, brighter future.
Days pass. Months pass. The backlog is starting to grow and the pressure is increasing. Years go by. You hire new developers to help with the project. There’s progress but it’s slow. You no longer sleep as well as you used to and fall into a darkness you have never experienced before. It isn’t until you hit rock bottom until you realize what’s going on…
You lied to yourself. The manager lied to you. You will never refactor that code and this is your life now.
What it is
On a more serious note, I’m glad Stix is now at a stage where I feel confident enough to share it with you. What started off as a wrapper around koa became something I’m happy to use and work on.
Stix is a framework that helps you build well-structured APIs, applications and command line tools without making any assumptions. It has been built to scale and also allow you to get started quickly.
It aims to be easy to use from the start and help you discover new features along the way to help out as you grow.
Looking at what needs it serves I guess you could say that stix is a module-based, TypeScript-first Node.js® framework (I like that… I think I’ll make that the repository description). What that means is that it’s not just an API. It goes beyond that, and it can be extended using modules.
What it does
Stix has core modules for database operations, automatically generated swagger docs, command line tools (including autocomplete) and more. It gets out of your way and allows you to only use the parts that suit your project in such a way that you can gracefully add modules without the hassle.
What are modules?
Don’t freak out! I know the term modules has been thrown around like salt on a snowy day, but it’s really not that impressive.
A module is the term used for a bundle of isolated code within your project. A module has its own routes, its own controllers, its own command line commands… You get the idea.
Modules are just regular directories with files. You can structure this any way you’d like (there is of course a recommended way of doing it). The only exception is that a module is required to have an entry point that matches the following interface:
Simple enough, right? Now as you can see, all of the methods are optional. However if you wish to do anything meaningful you’ll need to at least have an implementation for getConfig.
Note: using modules is optional. If you don’t like them, don’t use them.
Tooling
The skeleton comes with linting and a preconfigured ts-node-dev script in the package.json allowing you to immediately run your project.
It also comes with swagger documentation and boilerplate generators, both of which demonstrated in the quickstart video at the beginning of this article and have been written about in the documentation.
Wetland comes with migrations, which are technically not part of stix, but have been integrated with the stix CLI through stix-wetland.
We want more!
This article obviously doesn’t cover most all of the topics. But the documentation does! My wife Raphaela is responsible for building the beautiful website designed by Suraj which can be found here. Content wise, I’ve written at length about all the principles and features, and even included the API for the classes, enums and interfaces.
Why the name tho?
A couple of years ago I was working on a stack called the “swan stack”. Cool name right? I thought so too, until I started swapping out technologies and the name suddenly wasn’t as cool anymore. It first turned into swrn when I swapped out Aurelia for React and became skrn when I started using knex instead of waterline. Now time came to swap out knex for something else, I decided to pick a name that starts with a W and ended up with Wetland.
It was around this time that I decided that we needed something different for the API. A framework… It had to start with an S. I decided that sticks can be found at a wetland. Using the X from SpoonX I ended up with Stix.
Riveting story, I know.
Conclusion
I know there are many frameworks out there but I truly do believe stix adds value. We’ve put great care in the development experience and performance. None of the principles applied in stix are novel. They have been written about in length and applied in many products. This means that you don’t have to learn stix; you have to learn these design patterns, which I for one think is refreshing.
Want to help? Try out stix and share your thoughts! We’re still working on the documentation, but most of it is ready.
Read the docs. Clap, share, star the repository on github and tweet about stix. Plaster your city with stickers and posters and watch people get confused.
… Actually don’t do that last one, I don’t want to be held accountable for your vandalism.
And hey, I love you.
