feat: initial spike on referrals service #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
extracted from original implementation in storacha/console#142
3 tasks
use the example at // https://github.com/cloudflare/workers-sdk/tree/main/fixtures/vitest-pool-workers-examples/d1 to get testing in place
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
extracted from original implementation in storacha/console#142
This is a very simple REST service built as a Cloudflare worker. I've extracted it from its original implementation because I need to to be a scheduler as well, and that isn't well supported by the next-on-pages deployment style we're using in Next.js.
Users can create "refcodes" by email, look up "refcodes" and "referredby" by email and look up "referrals" by refcode. There is no authorization - this allows the service to work for unauthenticated users, but does mean that anyone can look up refcodes, referrals and referredBy for any email address - we only ever leak lists of refcodes and metadata about them, so I don't think this is too serious a leak, and some level of anonymous interaction is required to meet product requirements, but I do think we should move some of this into an authenticated context (ie, behind UCAN invocations) if we decide to keep scaling this functionality out.
Referral System Database Design
Two tables are used:
usersandreferrals.usersis used to store refcodes for users (identified by email address).referralsis used to record the refcode used by a user (identified by email address) during signup. Separate tables are used to avoid mutating rows in the database - a simple, immutable system is generally easier to maintain and reason about and while immutability of database tables isn't a hard requirement, it is a property this design strives to maintain.Operational Notes
We also introduce a set of scripts prefixed with
db:localthat make it relatively simple to maintain a local D1 database for development.