Over the past several years I’ve been working on a new application framework for nodejs. Monument is currently on it’s second major release.
What is Monument
Monument is focused on three things:
- Decoupled applications
- Developer Experience
- Performance and scalability
Decoupled Applications
When I started working on monument it grew out of the idea of using a pub/sub architecture to break up coupling in apps. Its internal architecture is the application of evented microservice architecture to the application itself.
The way that this works in monument is that every route listens for an event, we manage data through events, and custom event creation is easy. This makes development awesome and allows for independent development of features. For example, this is an event listener for a route:
events.on(’route:/:get’, (connection) => {});
It listens specifically for a GET request on the root route. Say that three times fast. Your handler receives a connection object that has everything you could need to handle the request.
We’ll get more into this in a follow on post about using events in monument to decouple your application.
Developer Experience
One of the things that Ruby on Rails gets very right and most node frameworks get wrong is the developer experience. So as I’ve been writing monument it has focused on making project standup easy. I’ve also looked for ways to automate common development tasks through the CLI tools. You can install the CLI with npm i -g monument-cli.
The CLI tool provides new project creation, route scaffolding and data scaffolding tools. That means you can rough out your entire REST API in the time it takes to describe your routes in JSON.
The other thing that plays a key role in the developer experience is the decoupled nature of monument apps. You can focus on what you are doing and not have to worry about the rest of the application while you do it.
Over the next couple of weeks we’ll walk through creating a simple web application and how to use the tools to do it.
Performance and scalability
monument is fast. It’s designed to be fast. But it also makes it easy to scale out sections of the app that are slow.
Because it uses an event bus, we can push anything we want out into a worker process that triggers the correct event when it completes. Need to crop images? Spin that into a worker process and trigger an event on completion. The receiver is already going to be waiting on that event so no work needed on the consumer end.
Need to scale out a process to another server? Same deal... the encapsulation of individual parts of the application keeps this black boxed. The other parts of the application don’t need to know or care what happens to generate the events they are listening too.
How can I use it?
So this is the easy part! Grab the CLI tools create a new project folder and run monument new .. Bam. Your first monument project is ready to rock and roll.
But what can I use it for?
Pretty much anything that you would use node for. It supports web sockets with a single config flag out of the box. It supports http2 or spdy, or any other http-style server protocol simply. It works great as a REST API or a web application.
The one weakness it has right now is that it still only supports a single template library for server side rendering. This is something that is being corrected in the soon to launch 3.0.0 release. Once that lands it will natively support react on the server, as well as most other major template libraries.
I am using it right now to run this site and it makes the progressive enhancement of the navigation super easy. Hit the right arrow key... it’s fast and clean.
I also use it for an image cropping service at work, and a bunch of other web applications I am playing with. It makes development of new projects really fast. Which is part of why I wrote it.
So you should be able to use it out of the box for anything that you want. Go for it! You won’t regret it.
The main documentation site has a lot more details about use as does the github repo.
Top comments (0)