Framework Unstable

Web Apps, Made Modular

Lariv is a completely open, fully extensible modular web library for Go.

main.go

package main

import (
	"github.com/lariv-in/lariv"
	"github.com/lariv-in/lariv/plugins/p_users"
	"github.com/lariv-in/lariv/plugins/p_dashboard"
)

func main() {
	// Register active plugins into kernel
	plugins := []registry.Pair[string, lariv.Plugin]{
		p_dashboard.GetPlugin(),
		p_users.GetPlugin(),
	}

	// Load config and start dynamic registry
	cfg, _ := lariv.LoadConfigFromFile("config.toml", plugins)
	lariv.Start(cfg, plugins)
}

Runtime Flexibility

Architected for Runtime Modularity

Every component in Lariv—from route handlers and database models to view templates and middleware—is designed to be dynamically replaced, patched, or modified at runtime.

Runtime Patch Keys & Overrides

Modify existing endpoints, HTML views, and pipeline behaviors dynamically without altering core source code using explicit registry patch keys.

Pluggable Component Architecture

Package independent domain logic into self-contained plugins. Register, swap, or disable modules cleanly during kernel boot.

Zero Monolithic Lock-In

Replace individual services or database schemas without touching adjacent plugins, preventing circular dependencies and monolithic decay.

Speed & Efficiency

Performance Benchmarks

Real-world benchmark comparisons based on common use cases.

Requests Per Second (RPS) Higher is better

Average Latency (ms) Lower is better

Data sourced from GitHub: UniquityVentures/benchmarks ↗ Benchmark Methodology & README ↗

Frequently Asked Questions

Got questions about modular Go architectures? We have answers.

Yes, Lariv is fully open source under the MIT license. It is designed to be highly reliable and scalable, specifically tailored for enterprise architectures where fast development iteration and low runtime overhead are vital.

Instead of packages importing each other directly and creating circular dependencies, plugins in Lariv register their tables, routing tables, and layout patches with a central Registry during kernel boot. This isolates code boundaries completely.

While GORM interfaces can target other databases, core framework plugins like p_users rely on PostgreSQL-specific capabilities (e.g. JSONB columns and dialect features). For standard deployments, PostgreSQL is the officially supported database.

Every view pipeline operates inside database transactions automatically when needed. This guarantees consistency so if validation fails at any point in the pipeline, the session state is safely rolled back.