tryunearth / rfcs Goto Github PK

Summary

When a user first registers for Unearth and goes through the onboarding process, they sync their Reddit saves with our backend. This is a necessary step in order to generate the personalized newsletters that are delivered at the user's preferred frequency.

One issue, however, that is not addressed by the current architecture of Unearth is the ability to re-sync Reddit saves. For example, if an Unearth user has saved five new things and unsaved a couple others via any Reddit client, Unearth has no way of knowing about these changes. Thus, the Unearth and Reddit databases do not have parity.

This RFC outlines one method in which to achieve parity across the two services by utilizing a serverless function to compare changes in the two databases and save the normalized version.

Basic Example

TODO

Motivation

It only makes sense for Unearth to have parity with a Redditor's saves on Reddit to continue using our service. Without it, eventually all of their Reddit saves will be surfaced and they will no longer need to receive their Unearth newsletter, unless they delete their account and re-register (in which case they will see many of the same emails).

I also think this is an interesting technical challenge to tackle, one I do not want to shy away from.

Detailed Design

On the frontend client, we can offer a button to "re-sync Reddit saves" (or perhaps do it periodically using scheduled jobs). When clicked, an HTTP request would be sent to our main Express server which contains the REST API. An example request might look like:

POST /api/v1/reddit/sync
{ 
  username,
  id,
}

Our API would receive this request and then make a request of its own to the serverless function via another HTTP request, passing along the user's ID (to be used later).

The serverless function, once spun up and ready to do work, would then need to do the following tasks:

1. fetch all of the user's saved things from the Unearth database
2. fetch all of the user's saved things from Reddit via a GET /api/v1/username/<username>/saved request
3. compare the two sets of saved things, determining what has been added and what has been removed. this can be done using Lodash's differenceWith method—see a basic example here: https://codesandbox.io/s/stupefied-shadow-wk8qe
4. the above step should create two new sets of data: additions and deletions. this data is then used to modify the Uneath database via:
   • additions: INSERT INTO… statements (things the user has saved since joining Unearth)
   • deletions: DELETE FROM… statements (things the user unsaved since joinging Unearth)

Once the above steps have been completed, the serverless function can spin down as now the Unearth database should mirror Reddit's into terms of the user's saved things.

Drawbacks

• will incur additional charges wherever the new component is deployed
• implementation cost (possibly), both in terms of code size and complexity

Alternatives

The Detailed Design section outlines using serverless one-off functions. I'll be honest and admit that I'm not entirely sure how these differ from something like a job queue (like RabbitMQ or Bull for Node.js). From my preliminary research, the changes I have proposed appear manageable for either process (serverless or job/messaging queue). This is a big reason for creating this RFC—I do not know which strategy to adopt. Thus, any and all comments are greatly appreciated!

Alternatively, we could also just not offload the data computation and leave it on the main Express server. I'd imagine this would become a bottleneck but then again, maybe we shouldn't worry about scaling prematurely.

Adoption Strategy

Being the sole developer of the project at this point, these changes would be widely adopted. If all goes well, we could even extend the serverless or job queue system to other tasks to improve scaling.

How We Teach This

Documentation would be key and is my preferred method of teaching any new concept. Tests would also be highly beneficial.

Unresolved Questions

• Is the aforementioned scenario a viable use-case for serverless? If not, how should this be architected?
• In addition to offloading said task from the main server, would using a job queue be helpful (combining serverless with jobs)?
• Because the data computation is offloaded from the main Express app, would the rest of app (like other API endpoints) still be performant?

What parts of the design are still TBD?

General implementation / design is major blocker at this time. A discussion of how to accomplish this in the most cost-effective manner would be awesome.