Antelope FrameworkModularity without the maintenance tax

Build for today. Stay ready for what changes.

Add features, choose providers and evolve your architecture without turning every decision into custom integration work.

Build your first module Explore the ecosystem

Less framework glue
Replaceable providers
Boundaries teams can own

~/projects · zsh

quickstart

# scaffold and run a modular application

$ ajs project init my-app

$ cd my-app && ajs project dev --watch

# watch mode reloads changed local modules

From the docs

See the boundaries in code.

The same typed primitives connect contracts, implementations, lifecycle and application configuration.

import { InterfaceFunction } from
  "@antelopejs/interface-core";

export const sendEmail = InterfaceFunction<
  (message: EmailMessage) => Promise<void>
>();

// Consumers call the capability.
await sendEmail({ to, subject, body });

A small public boundary

The consumer imports a typed capability, not the package that implements it. The runtime connects the implementation selected by the application.

import { ImplementInterface } from
  "@antelopejs/interface-core";

export async function construct() {
  const contract = await import("@org/interface-email");
  const implementation = await import("./smtp");
  ImplementInterface(contract, implementation);
}

export async function start() {
  await connect();
}

Runtime-owned lifecycle

construct() registers capabilities. start() runs after construction completes. stop() and destroy() release resources; owned bindings detach on destroy.

import { defineConfig } from
  "@antelopejs/interface-core/config";

export default defineConfig({
  modules: {
    api: {
      source: { type: "local",
        path: "./modules/api" },
    },
    database: {
      source: { type: "package",
        package: "@antelopejs/mongodb",
        version: "^1.2.0" },
    },
  },
});

Assembly stays explicit

Local and package modules share the same application model. Provider choice lives in configuration, outside consuming business modules.

Why Antelope

Modularity that earns its place in the stack.

Get the flexibility of a modular architecture without spending your time building and maintaining the machinery around it.

Ship with less glue

Add capabilities through one application model instead of wiring every package by hand.

Change decisions later

Select another compatible implementation while consumers keep the same interface.

Keep feature work focused

Give each capability a clear boundary so changes stay close to what they affect.

Grow without a reset

Add modules as the product expands without reorganizing the whole application.

Make the codebase legible

Use shared conventions so every team knows where a responsibility begins and ends.

Keep control of the stack

Mix ecosystem packages with local modules for the parts that make your product unique.

Useful from the first feature

Start simple. Stay adaptable.

Clean boundaries should create options now—not only rescue the codebase before a rewrite. Antelope makes modularity practical throughout the product’s growth.

01
Start lean
Choose only the capabilities the product needs today.
02
Add cleanly
Introduce the next feature without spreading it across the codebase.
03
Choose freely
Use an ecosystem provider or keep a critical implementation in-house.
04
Change locally
Evolve one implementation while its consumers keep a stable boundary.
05
Scale ownership
Give teams clear capabilities they can understand and evolve.

Built for changing products

Make today’s choice without locking in tomorrow’s.

Start with the fastest path, add what the product proves it needs and change compatible providers without dragging that decision through the codebase.

01Start

Pick what works now

Compose the capabilities needed for the first useful version.

antelope.config.ts

modules: {
  api: {
    source: { type: "local",
      path: "./modules/api" },
  },
  database: {
    source: { type: "package",
      package: "@antelopejs/mongodb",
      version: "^1.2.0" },
  },
}

02Grow

Add one focused capability

Extend the product through a module with a clear public boundary.

modules/catalog/

text

catalog/
├─ interface.ts
├─ module.ts
├─ config.ts
└─ tests/

03Adapt

Change the choice, not the app

Select a compatible provider while consumers keep the same interface.

antelope.config.ts

database: {
  source: {
    type: "package",
    package: "@org/database-provider",
    version: "^1.0.0",
  },
}

CLI workflow

One tool for the whole module lifecycle.

Scaffold, compose, test and run the application from one predictable workflow.

Project

ajs project initscaffold an application
ajs project devrun with module watching
ajs project buildprepare a production build

Modules

ajs project modules addadd a module source
ajs project modules listinspect application composition
ajs project modules updateupdate configured modules

Development

ajs module initcreate a module boundary
ajs module testrun local and published interface tests
ajs project dev --watchreload local modules in development

terminal — ajs

example workflow

$ ajs project modules add

$ ajs project dev --watch

# watch mode reloads changed local modules

Ecosystem

Compose with focused modules.

Start with the capabilities your application needs and keep every implementation behind an explicit boundary.

Authentication

Typed authentication and authorization capabilities.

auth-jwt

Database

Database interfaces with swappable provider modules.

mongodbrethinkdb

API

Typed API contracts and HTTP controller primitives.

interface-api

Module sources

Load modules from packages, Git, local builds or local folders.

packagegitlocallocal-folder

Explore all modules

In-processmodule runtime

TypeScripttyped interfaces and configuration

4module source types

Apache 2.0open-source license

Choose room to evolve

Ship now without cornering future you.

Build the backend the product needs today, with boundaries that leave tomorrow’s decisions open.

Start building Explore the ecosystem