Akan.js helps you minimize technical plumbing and focus on expressing business logic.
Akan.js also provides built-in application features and installable libraries so proven business patterns can be reused instead of rewritten.
This is especially important in the age of agentic coding. Agents write better code when business intent has one obvious place and conventions decide where the rest should go.
Workspace (monorepo)
Akan.js is monorepo-native. A single organization can develop multiple apps and shared libraries in one repository, and app execution, production builds, library development, and package management all happen from the workspace root.
Akan Workspace
appA imports libA
appB imports libA and libB
appC imports libB
code amount
20%
apps
80%
libs
App(apps): A deployable product surface. An app owns its pages, runtime entry, app configuration, assets, and app-specific domain code.
Common library(libs): Reusable business and utility modules shared by multiple apps. Authentication, files, payments, notifications, chat, admin features, and domain modules can live here and be reused safely.
When you run `akan create-workspace`, shared and util libraries are installed by default. These libraries are common libraries that can be used by all apps.
You can use common libraries in your created application (e.g. myapp). For example, you can use the shared library to provide admin page and file upload tool.
80:20 rule
A healthy workspace maintains a structure where 80% of the code is shared between apps, and 20% is specific to each app.
However, you don't have to force yourself to follow the rule. Just maintain the workspace with your heart, and the ratio will naturally be adjusted as you maintain it.
Workspace file structure
Apps and libraries share a predictable shape so pages, domain modules, assets, and runtime entries are easy to find.
An app runs through main.ts with AkanApp, while user-facing routes are declared under page/. Domain modules live under lib/ and can be shared from apps or libs.
You do not need to understand every file rule at first. Start by knowing whether you are changing a user-facing page, a business domain module, a reusable UI component, or the app runtime configuration.
Because the same conventions are repeated across the workspace, people and agents can navigate unfamiliar code without guessing the architecture from scratch.
Application or Library Anatomy
serverclientshared
Domain modules
Interface
lib/product/product.constant.ts · dictionary.ts · signal.ts
Data and service
lib/product/product.document.ts · service.ts
UI and state
lib/product/product.store.ts · Product.Template.tsx · Unit.tsx · View.tsx · Zone.tsx
Scalar modules
lib/__scalar/fileMeta/fileMeta.constant.ts
Service utilities
srvkit/account.ts · srvkit/guards.ts
UI and webkit
ui/Field.tsx · webkit/useFirebaseMessaging.tsx
base/ · common/
Pure shared logic
public/ · private/
Static assets
By following file rules, an application can remain extensible and reusable as it grows. The important question is not which framework layer to fight with, but which business intent you are expressing and where that intent belongs.
For example, in password-based login, the form belongs near the page or UI component, password rules belong near the shared domain definition, and persistence or security behavior belongs in the service layer of the domain module.
