From Fork to Framework, Part 6: ConnectRPC, Eden Libs, and the Framework That Pays for Itself

The Contract Layer: ConnectRPC and Protocol Buffers

The real power of Go and Flutter together is not either technology in isolation. It is the contract layer between them.

We use ConnectRPC with Protocol Buffers as the single source of truth for every API in our system. A service is defined once in a .proto file. The toolchain generates Go server stubs and Dart client code from that definition. If a field type changes, both the server and every client fail to compile immediately. There is no hand-written REST model code, no OpenAPI specification that drifts from the implementation, and no runtime type mismatch that reaches production.

ConnectRPC, developed by the Buf team, improves on raw gRPC in several critical ways. It works over standard HTTP/1.1 and HTTP/2, which means it runs natively in browsers without a grpc-web proxy. It supports JSON serialization alongside binary protobuf, making API debugging trivial with standard HTTP tools. It is wire-compatible with gRPC and gRPC-Web, so existing gRPC infrastructure works without modification. And it is dramatically simpler to operate: no Envoy sidecar, no protocol translation layer, no special-cased browser client.

The workflow is straightforward. Engineers define a service in protobuf. They run buf generate. They get a Go server interface to implement and a Dart client class to call. The types match. The fields match. The error codes match. The entire API surface is verified at compile time on both sides of the wire.

Eden Libs: The Shared Platform Monorepo

We consolidated our shared infrastructure into a monorepo called Eden Libs. In 19 commits across March 21 to 23, we built a platform layer that every product in our ecosystem consumes. It contains five packages, each with a distinct responsibility.

eden-platform-go: 14 Packages of Shared Backend

The Go platform library provides 14 packages that cover the infrastructure every multi-tenant SaaS application needs:

• Auth handles OAuth provider integration, multi-factor authentication, session management, and token lifecycle. Every product gets the same authentication flow without reimplementing it.
• Company hierarchy models multi-tenant organizations with parent-child relationships. Ancestor and descendant queries let us answer questions like “which companies are under this reseller” or “what settings does this child company inherit from its parent.” Settings propagate down the hierarchy with explicit override points.
• RBAC enforces role-based access control with role caps, meaning a company administrator cannot grant permissions that exceed their own company’s entitlements. This prevents privilege escalation in hierarchical multi-tenant environments.
• Audit provides a tamper-evident logging trail for compliance-sensitive operations. Every mutation records who did what, when, and from which IP address.
• Webhooks deliver events to external systems with adaptive delivery. The system adjusts retry intervals based on endpoint health, backing off intelligently rather than hammering failing endpoints.
• Bridge enables cross-domain event propagation. When a user is deactivated in the auth system, the bridge ensures that every product consuming eden-libs receives the event and takes appropriate action.
• Registry allows backend modules to register navigation items, widget configurations, and search scopes. The frontend reads the registry and builds the UI dynamically, which means adding a new module to the sidebar requires zero frontend code changes.
• pgstore and devstore implement the dual-store pattern described below.

eden-platform-flutter: The Frontend Shell

The Flutter platform package provides authentication orchestration (login, logout, token refresh, MFA challenge), a company switcher for users who belong to multiple organizations, and server-driven navigation that reads the backend registry and constructs the sidebar dynamically. Product teams do not build navigation. They register their modules with the registry, and the shell builds the navigation for them.

eden-platform-api-dart: Generated Clients

This package is entirely auto-generated from the .proto definitions. It contains Dart classes for every protobuf message and ConnectRPC client stubs for every service. Product teams import it and call typed methods. There is no manual HTTP code, no JSON parsing, and no model classes to maintain.

eden-ui-flutter: The Design System

Covered in Part 5, this package provides over 50 widgets and six brand presets. It is pure presentation: no business logic, no network calls, no state management opinions.

eden-cli: Developer Tooling

The CLI provides three commands: eden new scaffolds a new product with the correct directory structure and platform dependencies pre-configured, eden generate runs code generation for protobuf, Freezed models, and Riverpod providers, and eden dev orchestrates the development server with hot reload for both Go and Flutter simultaneously.

The Dual-Store Pattern

A critical design decision in eden-platform-go is the dual-store pattern. Every platform service depends on store interfaces, not concrete implementations. We provide two implementations:

devstore uses in-memory maps protected by mutexes. It starts instantly, requires no infrastructure, and resets between test runs. Developers iterate at the speed of unit tests during feature development. There is no database to provision, no migrations to run, and no Docker container to start.

pgstore uses PostgreSQL with sqlc-generated queries. It is the production implementation and the pre-merge validation target. The same service logic, the same business rules, the same authorization checks run against a real database.

The interface boundary is the key. Because services depend on Store interfaces rather than concrete types, swapping implementations is a one-line configuration change. This also makes the entire platform testable without database fixtures. Unit tests use devstore. Integration tests use pgstore. The service code does not know the difference.

Interceptor-Based Middleware

ConnectRPC supports interceptors, which function like HTTP middleware but operate at the RPC level with full access to typed request and response messages. Our platform provides three standard interceptors:

• AuthInterceptor validates tokens, resolves user identity, and injects the authenticated user into the request context. Every RPC handler receives a verified user without performing its own authentication logic.
• RBACInterceptor checks whether the authenticated user has permission to perform the requested operation, respecting company hierarchy and role caps. Authorization is enforced at the transport layer, not scattered across individual handlers.
• ObservabilityInterceptor records request duration, error rates, and response sizes. It emits structured logs and metrics for every RPC call without any instrumentation code in the handlers themselves.

Product teams wire these interceptors into their ConnectRPC server and get authentication, authorization, and observability for free. Domain handlers contain only domain logic.

Validation: Eden Circle in Eight Days

Architecture claims are cheap. Shipping products proves them. Eden Circle is our strongest validation.

Eden Circle is a team communications platform: messaging, group conferencing with screen sharing, presence tracking, push notifications, a timeline system, and AI features powered by AOSentry. Its domain has zero overlap with AODex, our AI workbench. Different product. Different users. Different features. Same platform.

In eight days and 50 commits across March 11 to 19, a single engineer built and deployed the entire application. Eden Circle consumes the same authentication, authorization, company management, audit logging, and event bridging packages that AODex uses. The engineer wrote zero authentication code, zero RBAC code, and zero multi-tenancy code. They wrote messaging, conferencing, and presence. The platform handled everything else.

Docker Compose configuration and Helm charts for Kubernetes deployment were included in those 50 commits. This was not a prototype. It was a deployable product with production infrastructure definitions.

The Framework Investment Math

The question every engineering leader asks about framework investment is whether it pays for itself. Here is the arithmetic.

The framework cost seven days. The first product saved two to three weeks. The second product saved three to four weeks. By the third product, the framework has paid for itself multiple times over. Every subsequent product starts with authentication, multi-tenancy, RBAC, audit logging, webhooks, a design system, and deployment infrastructure already working. The marginal cost of the next product is only its domain-specific features.

The Registry Pattern: Server-Driven UI

The registry pattern deserves specific attention because it solves a coordination problem that plagues multi-product platforms. In a traditional architecture, adding a new module to the application requires frontend changes: a new route, a new sidebar entry, a new set of navigation guards. In our architecture, the backend registers its capabilities with the registry, and the frontend shell reads the registry and builds the UI dynamically.

When Eden Circle’s backend starts, it registers its navigation items (Messages, Meetings, Timeline), its search scopes (messages, channels, users), and its widget configurations with the platform registry. The Flutter shell reads these registrations and constructs the sidebar, search interface, and dashboard without any Circle-specific frontend navigation code. If Circle adds a new feature, it registers a new navigation item, and the sidebar updates automatically on the next app launch.

This pattern inverts the traditional dependency. Instead of the frontend knowing about every module, the modules tell the frontend about themselves. It is the same principle behind plugin architectures in IDEs and CMS platforms, applied to a multi-product SaaS ecosystem.

The Lesson

This series began with a fork of LibreChat and traced the path through Python, Svelte, Ruby on Rails, Go, and Flutter. Each phase taught us something. Python taught us that monoliths are fine until they are not. Svelte taught us that framework lock-in is expensive. Rails taught us that developer ergonomics matter but runtime characteristics matter more. Go taught us that simplicity scales. Flutter taught us that a single codebase is not a compromise.

The final lesson, the one that ties the entire series together, is about the glue. The most valuable code in our ecosystem is not the Go backend or the Flutter frontend. It is the .proto files that define the contract between them, the platform packages that implement cross-cutting concerns once, and the CLI tooling that makes starting a new product a single command. The most valuable code you write is the code that makes the next project faster.

Invest in the glue. Everything else follows.