@whop-apps/feed

The Feed Component (tm)

this is something i (jordan) cooked up in feb 2024
now (may 2024) its getting 12+ mill requests / day
i shall write some docs now...

High Level Architecture

The "feed component" consists of 3 parts:

1. a backend api that stores posts, reactions and feeds
2. a frontend client that fetches this data, manages the state of posts on the client
3. a backend client that allows apps to run server logic before performing mutations

Backend API

The backend API is a rest api deployed on Cloudflare workers, that connects directly to dynamo db via https as its only data source. It is tightly integrated with the whop api v5 for authentication / user queries.

Post + Feed + Reaction structure

To interact with the feed component, you must perform requests on behalf of a "whop app". This can be done either "server to server" through the use of an api key, or through a user token. generated on behalf of an app.

• Each app owns many "feeds".
• Each feed has a collection of "posts"
• Each post, can optionally contains a collection of "children", which are posts, creating an infinite tree.
• Each post may have many reactions. Each reaction is of a certain type.
• A user may only react to a post once per reaction type.

Frontend Client

• The frontend client holds a bunch of entities (feed, post, reaction, user) in a pool (entity pool).
• These entities are "subscribable", essentially allowing react components to subscribe to changes that happen on the entity.
• The pool is manipulated by "actions" which are objects that can be applied and reverted. Actions are submitted to the backend client.
• They can either be approved / denied here, then they are forwarded to the backend api, which applies the actions to the database.
• Actions mutate entities, and these entities are stored in an "action" table.
• The frontend client directly queries these actions, and applies the changes to its local version of the pool.
• The entity pool uses ids stored on its entities to build up in memory "collections" of entities to match the relations described above. The pool maintains these collections automatically.

Backend Client

The backend client is a very thin wrapper around the rest api allowing app developers to easily "accept" or "deny" actions, as well as perform side effects on success.

Custom types

To allow developers to use this component for more than just basic "text" posts, the component exposes the concept of "custom" data, stored as JSON inside the DynamoDB row. Custom data is able to be stored on post and reaction and feed.

A schema is able to be defined for each of these fields. This is done using createFeedDefinition. This definition is able to fully encode the entity relationships from above. : a feed of type A may contain posts of type B, but not posts of type C. Posts of type C are only able to be stored as "children" of posts of type B

Data submitted for these custom fields, is validated by the backend client. The frontend client is designed to be "typesafe" wrt to these types out of the box. (however, there are currently issues in this regard)