Design Notes

A small set of notes on the framework’s deliberate design choices - what it encapsulates and why, and what it deliberately leaves out of scope.

Encapsulation Pattern

Microbus employs the principle of information hiding and opts to encapsulate the underlying technologies behind its own simplified interfaces. There are various reasons for this pattern:

  • Providing a cohesive experience to developers
  • Enforcing uniformity across all microservices brings familiarity when looking at someone else’s code, lowers the learning curve, and ultimately increases velocity
  • The underlying technology can be changed with little impact to the microservices
  • Oftentimes the underlying technology is more extensive than the basic functionality that is needed by the framework. Encapsulating the underlying API enables exposing only certain functions to the developer
  • The framework is in control of when and how the underlying technology is initialized
  • The framework is able to seamlessly integrate building blocks together. This will take shape as more building blocks are introduced
  • Bugs or CVEs in the underlying technologies are quicker to fix because there is only one source of truth. A bug such as Log4Shell CVE-2021-44228 would require no code changes to the microservices, only to the framework

One example of this pattern is with the configuration of microservices. Rather than leave things up to each individual developer how to fetch config values, the Connector defines an interface that encapsulates the underlying implementation. Today, the framework looks for config values in a config.yaml file. In the future, it might be extended to fetch configs from a remote location.

Out of Scope

Microbus’s focus is on building and operating microservices at scale. The following areas are currently out of scope:

  • User interface - Microbus is a backend framework. Its link to the front-end are microservice endpoints that respond with JSON to single-page front-end applications, and an OpenAPI document that catalogs those endpoints. It is possible for microservices to generate HTML but Microbus provides no tooling in this area.
  • SDLC automation - Automating the SDLC of Microbus solutions is currently out of scope.
  • Databases - The choice of database depends heavily on the use case of the solution and as an enabling technology, Microbus takes no sides on this topic. Sequel is a companion project to Microbus that facilitates the development of CRUD microservices in a SQL database.
  • AI - Artificial intelligence is currently out of scope, except in the context of coding agents.

Some of these areas have room for contributors to step in. Contact us if you want to get involved.

Backward Contribute Contact Forward