GitHub
265
Created 2 years ago, last commit a year ago
2 contributors
96 commits
Stars added on GitHub, month by month
0
0
0
0
0
0
0
0
0
0
11
12
1
2
3
4
5
6
7
8
9
10
2023
2024
Stars added on GitHub, per day, on average
Yesterday
=
Last week
0.0
/day
Last month
0.0
/day
Last 12 months
0.0
/day
npmPackage on NPM
Monthly downloads on NPM
11
12
1
2
3
4
5
6
7
8
9
10
2023
2024
README

Actio

The Node.js framework for monoliths and microservices.

License: AGPL v3

Actio is a modern, batteries included Node.js (Typescript) framework for your backend applications. It enables you to effortlessly switch between monolithic and microservices architectures.

Start out with a monolith and turn it into microservices without changing your code once you need to scale!

Get started.

npm i -S @crufters/actio

Simple

Actio values simplicity and elegance, because enjoying coding makes you more productive.

import { Service, Servicelike, startServer } from "@crufters/actio";

interface MyEndpointRequest {
  name?: string;
}

@Service()
class MyService implements Servicelike {
  constructor() {}

  // this method will be exposed as an HTTP endpoint
  async myEndpoint(req: MyEndpointRequest) {
    return { hi: req.name };
  }

  async _onInit() {
    console.log("MyService: _onInit runs whenever the server boots up.");
  }
}

startServer([MyService]);

Dependencies made easy

Your services can easily call each other just by accepting a constructor parameter:

@Service()
class MyService implements Servicelike {
  constructor(otherService: MyOtherService) {}
}

Monolith or microservices? Actio blurs the line

Service calls are just function calls. Function calls become network calls simply by configuring Actio with envars:

Without configuration, service calls are just normal function calls:
--------------------------------
|  LoginService     <-|  <-|   |
| PaymentService  ----|    |   |
|  OrderService   ---------|   |
-------------------------------|
 instance address
     0.0.0.0
  no Actio config


With some lightweight configuration a true services based
architecture can be achieved, without code changes:

-------------------                     -----------------
| PaymentService  |-------------------> | LoginService  |
|  OrderService   |-------------------> |               |
-------------------                     -----------------
 instance address                        instance address
     0.0.0.0                                 0.0.0.1
envar LOGIN_SERVICE=0.0.0.1

Calls to the login service become network calls automatically.

Batteries included

Actio is batteries included: it comes with services that help you bootstrap your system (but tries to not force you to use these) faster:

  • Authentication service for login, register, oauth (facebook etc.).
  • KeyValue service for saving unstructured data without creating yet another anemic endpoint/service.
  • File service for file upload. Upload to a local disk or to Google Storage etc. in production.
  • Config service for handling public configuration and secret values.
  • System service for inspecting the Actio runtime and enabling building tools upon Actio (such as API explorers etc.).
  • Payment service: a double entry ledger system with Stripe and other payment provider support.
  • ...and many others that the community might find useful.

Built with infrastructure in mind

Real world apps need persistence and many other infrastructure elements. Actio manages your infra dependencies just like your service dependencies.

  • Postgres
  • Redis
  • Many more coming

Testing without the hassle

Run integration tests easily including all of your services and infrastructure dependencies. No need for mocking.

Namespaced for server savings

Actio enables you to run multiple projects from the same single server by namespaces. Save on server and maintenance cost.

Firm service boundaries

Actio isolates your services - no more sidestepping of service boundaries, be it intentional or accidental. Each service is a black box for other services, which enable you to reimplement services without breaking depending services.

The dependency injector makes sure your service tables live in different databases entirely - joins won't work across services. This and similar constraints enable you a seamless and refactor free transition to microservices - but also ensures your monolith doesn't became overly tightly coupled.

Examples and tutorials

For examples and tutorials see the Getting started guide.

Credits

Inspired by other microservices systems such as Micro and the author's previous work with Asim Aslam. Author: János Dobronszki. Contributors: Dávid Dobronszki, Asim Aslam, Viktor Veress.