Hello Gophers,
I’d prefer to introduce ZATRANO, an open-source Go software platform for constructing production-grade software program.
The present v2 structure is a big redesign quite than a easy model improve.
The principle concept is straightforward:
Go offers the language. ZATRANO offers the appliance platform.
As an alternative of placing each software functionality into one framework core, ZATRANO separates the runtime basis from the appliance ecosystem.
The Structure
ZATRANO is break up into two independently maintained Go modules: the framework module and the packages module.
The framework repository accommodates:
- a small runtime kernel
- dependency-neutral contracts
- software bootstrap
- CLI
- HTTP primitives
- routing
- middleware
- configuration
- dependency container
- lifecycle administration
- core infrastructure
The packages repository accommodates non-compulsory software capabilities resembling:
- authentication
- classes
- validation
- database
- ORM
- queues
- notifications
- scheduler
- cache
- localization
- AI
- RAG
- brokers
- OAuth
- WebAuthn
- billing
- OpenAPI
- GraphQL
- and different software companies
The essential half is that the kernel doesn’t depend upon the packages ecosystem.
The dependency path is deliberately one-way:
Utility → Framework → Contracts & Kernel
Utility → Chosen Packages
This retains the runtime basis small whereas permitting the appliance layer to develop independently.
Why Construct It This Approach?
One downside I needed to discover is the rising hole between “a Go HTTP framework” and “an entire manufacturing software platform.”
Go offers builders wonderful primitives, however a manufacturing software nonetheless requires choices and integrations round authentication, classes, database entry, queues, caching, notifications, AI, safety, configuration, lifecycle administration, and lots of different considerations.
ZATRANO makes an attempt to offer these capabilities with out turning the kernel right into a dependency-heavy monolith.
One other essential precept is specific enablement. An software solely permits the packages it truly wants.
The aim is:
- Small kernel
- Steady contracts
- Strongly typed developer APIs
- Choose-in capabilities
- Express software boundaries
quite than one huge framework core.
A New Utility
A ZATRANO software could be created with:
zatrano new myapp
cd myapp
go run ./cmd/app serve
Packages can then be explicitly enabled as wanted:
go run ./cmd/app bundle:allow auth
The platform additionally offers a kernel-only minimal mode for functions that need to begin with a good smaller floor.
One Architectural Element I’m Significantly In
ZATRANO makes use of a dependency-neutral contracts layer as the general public ABI of the kernel.
The intention is to maintain the steady software boundary impartial from implementation packages.
Conceptually:
contracts → steady dependency-neutral ABI
kernel/* → strongly typed implementation
From(app) → typed developer API
This lets the ABI stay small whereas holding the precise developer expertise strongly typed.
Repository
Framework: GitHub – zatrano/framework: A Go software platform for constructing production-grade software program. · GitHub
Packages: GitHub – zatrano/packages: Official ZATRANO packages · GitHub
Suggestions I’m Trying For
I’m considering suggestions from skilled Go builders, notably round:
- Is that this separation between runtime/kernel and software capabilities helpful in Go?
- The place ought to the boundary between a framework kernel and an software bundle be?
- Does a dependency-neutral contracts/ABI layer present significant long-term worth?
- What would you anticipate from a production-grade Go software platform that present frameworks don’t present?
I’d notably respect architectural criticism quite than simply characteristic requests.
Thanks.
