Re-Shell: One CLI for Microservices and Microfrontends

Every project I joined for the better part of a decade started the same way. A new repo, an empty pnpm workspace, and then two or three days of quiet, unglamorous wiring. Set up the gateway. Decide how the frontends talk to the services. Pick a component library and bolt it on. Write the health check endpoints everyone forgets until something falls over in production. By the time the actual product work started, I had already rebuilt the same scaffolding I had built on the last three projects, slightly differently each time. Re-Shell came out of being tired of that. It is my open-source full-stack development platform, and its whole reason to exist is to stop me from re-stitching the same wiring on every new project.

The problem with glue scripts

The usual way teams solve this is glue. A bash script that scaffolds a service. A README section nobody updates. A copy-pasted Vite config that drifts out of sync with the one in the other repo. None of it is wrong, exactly, but it adds up to a toolchain that exists only in the heads of two or three people and a folder of half-documented scripts.

The deeper issue is that microservices and microfrontends are usually treated as two separate worlds with two separate sets of tooling. The backend team has its generators and its conventions. The frontend team has its component library and its build setup. The contract between them lives in a Slack thread. When something changes on one side, the other side finds out at runtime. I wanted one cohesive toolchain that treated both halves as part of the same system, because in practice they are.

What Re-Shell actually is

Re-Shell is a pnpm monorepo that publishes an npm organization called at-re-shell. It ships three packages, and the split matters.

The first is the CLI. This is the part you actually run. It scaffolds new services and frontends, generates code, runs health checks across the workspace, analyzes bundles so you can see what is bloating a frontend, wires up CI/CD, and handles migrations when conventions change between versions. It is the front door to everything else.

The second is the UI package, a Shadcn-first React component library. I went with Shadcn as the foundation deliberately. I did not want a heavy, opinionated component framework that fights you the moment your design diverges from its defaults. Shadcn gives you components you own and can edit, and Re-Shell builds a consistent layer on top of that so every frontend scaffolded by the CLI starts from the same vocabulary.

The third is the contracts package, shared TypeScript contracts that sit between the UI and the CLI. This is the piece I am most deliberate about. It is the type boundary that keeps the two sides honest. When the CLI generates something the UI consumes, the shape they agree on lives in one place, not in two slightly different interfaces that drift apart over six months.

What a full-stack platform means here

I use the phrase full-stack platform carefully, because it is easy to oversell. I do not mean Re-Shell does everything. I mean it owns the seams. The seam between a microservice and the gateway. The seam between a microfrontend and the shell that hosts it. The seam between a generated backend and the typed client that calls it. Those seams are where projects rot, and they are exactly the parts people skip when they are moving fast.

So the platform takes a position on the boring decisions. Where do health and observability hooks go. How are services registered. How does a new frontend get composed into the shell without a manual integration ticket. None of these are hard problems individually. The value is that they are decided once, consistently, and the CLI enforces them so they stay decided.

Where AI fits without taking over

A fair amount of Re-Shell's generator and migration code was written alongside Claude. The honest version of how that worked is less exciting than the marketing version. Claude is good at the wide, repetitive surface area, the kind of work that is tedious precisely because it is so similar across cases. Keeping five backend generators structurally aligned, writing the migration that rewrites old scaffolding to a new convention, filling in the long tail of edge cases in a templating layer. That is real time saved.

What it does not do is decide the architecture. The contract boundary, the choice to make contracts a first-class package, the decision about what the CLI should own versus what it should leave alone, those came from me having lived with the failure modes. An agent will happily generate whatever you point it at, including the wrong abstraction, very efficiently. The leverage comes from knowing what you want first and using the agent to get there faster, not from asking it what you want.

What it has changed for me

The concrete result is that a new project no longer starts with three days of wiring. It starts with the CLI and a few decisions that are actually about the product. That is the whole point. A platform like this is not impressive because of any single feature. It is useful because it removes a category of recurring work that never deserved to be done by hand more than once. Re-Shell is open source and still evolving, mostly in the direction of having stronger opinions, not weaker ones. The seams it owns are the seams I no longer think about, and that is exactly the amount of attention they were always worth.