Problem
Our current legacy architecture has major design issues which slows new feature development, creates inconsistency in the product, and causes instability.
Architecture of Duplicated Code
There are several concerning patterns:
Key management and signing is owned by the frontend on web, but is owned by the daemon on desktop. This applies to all "writes" of p2p or permanent data
On web, any privacy functionality is implemented by the front end, who offers fewer features than the gRPC API. On desktop, these functions are generally not needed, but some things are still managed by the daemon, such as deletion.
The daemon gRPC API is not optimized for the web, where we need to avoid waterfall request patterns for performance reasons.
As an overall result, we have a lot of functionality that needs to be re-implemented in different environments and languages. This bloats the amount of code that we have to write and maintain. This also means that a feature will land to the desktop app at a different time as it lands for web. Concise code allows developers to efficiently iterate on the product before PMF. The more code we have, the more bugs we have.
Missing Data Definitions
The permanent data at the heart of the hypermedia protocol is undocumented, as is our public-facing API. The permanent data is only documented by the code which writes it, which is mixed across frontend and backend. This lack of rigorous data definition has already led to inconsistencies in our permanent data which we now need to support forever. With formal data definitions for the permanent data and APIs, we would safely accelerate protocol development, and enable external developers to participate in the ecosystem.
Poor Client Caching
Our current client is built on React Query, which does not support normalization. The cache is keyed based on the query, not based on the resource. This leads to situations where the frontend waits on a query even when it already has partial or stale data for that resource. The result is a bad web experience when the user is offline or on slow network.
Solution
With an incremental migration, we can gradually adopt the new patterns in our codebase for new code.
Seed API
The formalized Seed API, (currently looking at XRPC). There will be several variants/extensions for the different interfaces (domains) where the API will serve:
Inside Desktop App
Public HM Web
Tenant Sites on Seed Infra
Self-Hosted Sites
Seed Host
Seed Notify
Seed Pay
p2p Sync API
The services might include: Resources/Core reading, Feed, Search, Writing + Publishing, Pay, and Host
Seed Client
The new Seed TypeScript Client will be aware of the data schemas and provide a normalized cache for the front ends and other applications.
The client would also manage keys and signing of permanent data.