Capricorn

I've built UI frameworks, I've constructed design systems, I've created content, and I've gathered data. So how do you put everything together?

Development trends come and go, some stay, and some are forgotten, but how do you know what works? You practice. Capricorn is a project to explore frontend architecture with the current trends of monorepos and micro UIs. I can configure different architecture or combinations of tools to test or prove a concept or idea or try a new system or workflow.

There's a variety of tooling for monorepos, and they all work, but what about workflow? Which is best? The answer is whatever works best for your situation. Is your team large or small? Is your department made of several teams, and is it divided by domain or by functional area? I built Capricorn to model different scenarios based on various requirements.

A single monorepo to rule them all

You have to start somewhere and might as well do it with what many already understand. We're often used to working in a monolith, a single application in a single repository, so why not evolve it into a single monorepo by breaking the application into microservices and frontends? Maybe the team is small enough, and that's all they need, but for larger or distributed teams, perhaps not.

I can model this using tools like NX or Lerna and a variety of frameworks and utilities using Capricorn.

A monorepo for each domain

Each domain team has its monorepo. This is a more refined scenario and prevents a single monorepo from becoming a more complicated monolith, but it is not without its drawbacks. Assuming the need for a unified user experience, the architecture is complicated by having to somehow bring the diverse parts together into a single user interface.

A monorepo for each functional area

Frontend, backend, testing, and all the disciplines that make an application could each have their monorepo. In this case, I can configure Capricorn for a monorepo for micro frontends, a monorepo for microservices, and another for testing.

How does it work?

It's not complicated. A repo with several branches will do. However, Capricorn isn't a product with a deliverable. The deliverable is whatever report I have to create for a given situation or client. To that end, I keep it simple and rely on NPM modules and configuration templates.

I also keep patterns on hand for different micro frontend architectures and can test them with actual data. Usually, I use The Movie Database for data from a REST API, and for static content, I'm an artist. I have plenty. So with content in hand, either local or remote, I can explore some different architectures.

Here are a few options I've tried.

A single SPA

The single SPA combines multiple applications (frameworks) on a single page without refreshing. This is how most modern frameworks work and is a good strategy when managing state, routing, and other things. This pattern works fine if you use a single framework like React but is difficult if you mix frameworks.

Multiple SPAs

The multiple SPA combines independent applications at different URLs and uses a package manager like NPM for shared functionality. This is a wonderful solution for applications that use various frameworks but presents solvable problems of state management and routing across independent SPAs.

Iframes

Isolating multiple applications into iframes, each of which shares an API exposed by the parent frame. Just say no. Using iframes is a way of adding new problems with complex solutions if dealing with shared state across iframes.

Events

Modular applications communicate with each other over a single event bus. Fairly old school but manageable with some careful planning. An event broker is necessary.

Components

Component libraries are dependencies of a host application and are imported by the host application when/as needed. Atomic components can roll up into micro-frontends that are components of a host application.

Which is best? There is no universal solution, but I can help you if you want to know what is best for you.