From the Ooloi Front: Towards Hello World

Right. Quick update from the development trenches.

When I completed Ooloi's backend engine in July, starting work on the frontend interface revealed the anticipated cascade of architectural requirements that needed systematic resolution first.

Here's what emerged, in order:

1. Collaborative Undo/Redo Architecture (ADR-0015)
Thinking about frontend-backend relationships immediately raised the question: how does undo/redo work in a multi-client, distributed collaborative setup? The answer required a three-tier architecture separating backend piece changes (coordinated via STM) from frontend UI changes (local to each client).

2. Universal Settings Architecture (ADR-0016)
The insight that there should be no global application settings, only per-piece settings living inside each piece, led naturally to implementing settings not just on the piece level, but across all levels of the hierarchy. Any entity – piece, musician, staff, pitch – can now have configuration attributes via a unified defsetting macro with lazy storage and automatic VPD support.

3. Component Lifecycle Management (ADR-0017)
Multi-scenario deployment demanded rock-solid system architecture using Integrant. This needed to be in a stable architectural form – wiring, lifecycle boundaries, failure modes – before setting up the actual components with proper dependency injection, partial failure handling, structured error codes, the full production suite.

4. Automated gRPC Generation (ADR-0018)
With component architecture sorted, I could tackle the actual gRPC implementation: automating API endpoint generation for native Java interop across hundreds of methods, plus bidirectional communication for real-time collaboration. Manual implementation at this scale would be architecturally impossible.

5. In-Process Transport Optimisation (ADR-0019)
Combined deployments (frontend and backend in same process) were using unnecessary network transport. Implementing automatic in-process gRPC transport delivers 98.7–99.3% latency reduction whilst preserving external monitoring capabilities.

6. TLS Infrastructure (ADR-0020)
Secure connections are essential for distributed deployments – conservatory intranets, corporate environments, cloud SaaS situations. Auto-generating certificates with full enterprise capabilities makes this transparent whilst supporting everything from development to production.

7. Authentication Architecture (ADR-0021)
Finally, distributed deployments require comprehensive authentication and authorisation. Pluggable JWT-based providers scale from anonymous sessions to enterprise LDAP integration. This is fully designed and will be implemented as deployment scenarios require.

Current Status: About 95% of the above is implemented, tested, and production-ready.

Next Steps: Finish the auto-generated gRPC Java interop interface, then create an actual frontend client of the 'Hello World' variety and ensure it runs and communicates across all deployment scenarios.

The rather encouraging discovery throughout this process was how readily the existing functional architecture accommodated these enterprise concerns. Vector Path Descriptors naturally supported universal settings. STM transactions elegantly handled collaborative undo operations. The component system absorbed authentication providers without strain. When features like collaboration or security slide cleanly into place, it's not luck – it means the architecture wanted them there. That's what sound foundations do.

Worth noting: collaboration isn't something tacked on later. It's integral to the architecture from the ground up.
​
Right. Back to the gRPC generator.