Solve Singapore Slump

[CowMuon]

Placeholder story for fixing problem serving app to other geographic regions, notably Singapore.

This is for an immediate solution for the long app load times experienced in other geo-regions that Heroku is not well configured to serve correctly (and not, getting off Heroku to solve the problem.)

In addition to the user submitted reports from the dydx community, we have independently tested and confirmed that (Desktop) load times in Singapore are ~17 seconds, compared to ~4 seconds in North America. (Interestingly, Taiwan clocks in a ~11 seconds, a full 6 seconds faster than Singapore

This is work to be done in Cycle 1 Sprint 7 (aka our "extra" sprint) and needs to be fully tested and deployed (and confirmed in production) by 2/17.

[kurtisassad]

There are two parts to optimizing loads from singapore.

1. static content (Assets that don't rely on API calls)
2. dynamic content (Assets that rely on API calls)

Static content has been fixed by making a dydx pointing from our cloudflare to the server dns. Then we will give them our dydx.commonwealth.im as a DNS target which when they point to, it will cache the static content close to their proxy.

Dynamic content is more difficult because it can not be cached close to the caller. As a result there are two ways to deal with this.

1. start up server in Asia, give them this server. When their proxy requests for dynamic content it will hit this server which will have faster response times.
2. refactor to make our dynamic content smaller.

The issue with 1, is that this looks difficult and I am unsure how to resolve it. Because not only do we have to have our server in Asia, but we will need to replicate the DB there and ensure consistency with the one in America somehow. It looks like a difficult task.

So that leaves us with 2. It is currently blocked by the state refactor. The reason for this is that the dynamic content consists of pages that rely on our API calls. The chain of blocked issues looks like:

Singapore Issue -> Status route split -> State refactor -> Finishing React refactor

[kurtisassad]

There are 3 ways I see that we could speed up asia's response time:

1. (Global - code splitting) Finish code splitting which will improve long js execution time. Blocked by state refactor
2. (Easy - improve caching on CDN) Give them our commonwealth.im url (dydx.commonwealth.im), put images behind CDN. Also we could look into a SSR framework to prerender and cache some portions of dynamic pages on CDN.
3. (Hard - replication) We replicate our setup in a master/slave configuration in order to give the user quick response times via server being close to client. See the picture for example architecture setup. Arrows indicate the flow of data.

[kurtisassad]

Current status of singapore ticket.

ready for review now

image-cdn (reduce ttfb for images)

future plans

state-reafactor (reduce amount of static data/bundles we send to client) status-refactor (reduces amount of dynamic data we send to client, should be done after state refactor)

canceled due to complexity

startup second server in asia (reduces ttfb for dynamic content)

(Note, FCP speedups propagate to LCP)