search

Eximchain / terraform-aws-dappbot

Terraform infrastructure to run ABI Clerk
Other
0 stars 1 forks source link

Create Shared Infra, Shared Source Architecture #29

Closed john-osullivan closed 5 years ago

john-osullivan commented 5 years ago

Overview

This issue describes how we could have one modified dappsmith dapp which, rather than generating source components for a specific ABI, instead parses an ABI JSON within the React runtime to generate the dappsmith UI for the user. The trade-off is that each dapp does not have its own source, so this is incompatible with serious customization. The upside, however, is that the dapps are basically just pages in a site, so the underlying JS and CSS assets for each dapp are all identical. We also don't need to store as much data per dapp.

Note that the key difference between this and the architecture from issue #8 is that every single dapp "generated" on this architecture would share the same source, so once the user has hit any of them, they've cached all of them. In issue #8, each dapp gets custom source could which gets bundled into a file with a different hash, so all user & Cloudfront cacheing is per each dapp.

Request Flow

In this scenario, the cheapest price point would let you view your dapp at shared.dapp.bot/0xAnything.... Our generalized dapp lives in an S3 bucket behind a single Cloudfront & Route53, shared.dapp.bot. When the user submits their dapp, we save the deployed address and ABI in DynamoDB or an S3 bucket. When the user then loads shared.dapp.bot/0xAnything..., that will miss the Cloudfront cache, not find an S3 object, and instead return the shared.dapp.bot index.html page. This page spins up the React app which then parses the path argument, 0xAnything..., into a request to the S3 config bucket. The pages finds the 0xAnything ABI, deployed address, etc in the bucket, then uses the ABI to generate the contents of the TxSidebar and TxMainPane from dappsmith.

Cost Rationale

All of the 2.7MB of page assets are shared across every dapp, so once the user has loaded any of the dapps on shared.dapp.bot, loading future dapps just requires fetching the ABI. Loading data from the Cloudfront cache to the user is still our biggest cost point, so if we can get the user cache to not rely on Cloudfront more often, that's a big cut to our dominant cost term.

Changes Required

Some of these changes would also be required in Issue #8 , I just want to be complete about what would be required at this point to implement the above strategy:

  1. One S3 bucket, Cloudfront Distribution, and Route 53 record for shared.dapp.bot.
  2. Adapting dappsmith to the new shared.dapp.bot client, letting it parse routes and make the additional follow-up queries.
  3. Updates to abi-clerk-lambda so that when you create an app, it actually just creates a DynamoDB record or S3 object -- no CodeBuilds or anything like that.
Lsquared13 commented 5 years ago

Superseded by more specific issues