aragon/apm-serve

Web 2.0 server for Web 3.0 APM hosted dApps

apm-serve

Web 2.0 server for Web 3.0 APM hosted dApps

Goal API

• dapp.aragonpm.com -> serves content from latest version of dapp.aragonpm.eth in the mainnet
• dapp.rinkeby.aragonpm.com -> serves content from latest version of dapp.aragonpm.eth in rinkeby (requires setting ENS address)
• 1.2.3.dapp.aragonpm.com -> serves version 1.2.3 of dapp
• voting.aragonpm.com/?json=true -> serves json with all versions of voting.aragonpm.eth with smart contract addresses and contentURIs
• voting.aragonpm.com/?json=true&version=1.2.3 -> serves version information for voting.aragonpm.eth 1.2.3

What about running it on myregistry.eth?

• Use the docker image to deploy to your hosting service of choice and configure it for your registry

Roadmap

• v1: HTTP serve contentURI of a given package, for different networks and versions.
• v2: JSON API
• v3: DNS gateway like ipfs-gateway, that would allow just running 1 instance of apm-serve and people being able to serve registries or specific content just by configuring DNS.

apm-serve's Issues

Update readme with new URL scheme

Now the testnet name is the least significant part of the URL

dapp.rinkeby.aragonpm.com -> rinkeby.dapp.aragonpm.com

Make network subdomain the last one rather than first

dapp.rinkeby.aragonpm.com -> rinkeby.dapp.aragonpm.com
bitconnect.open.rinkeby.aragonpm.com -> rinkeby.bitconnect.open.aragonpm.com

Name

By my personal preference order:

• apm-serve
• apm-gateway
• apm-server

Fallback to second last version if latest version is unresolvable

During deployments, mainnet.aragon.org and rinkeby.aragon.org usually come down for a few minutes because apm-serve is trying to get the latest content that the connected IPFS node doesn't know have cached yet.

Ideally we would wait a maximum of 500ms to 1s on resolving the latest version of a package, before falling back to loading the last version.

To avoid having false fallbacks in times of high load, we could cache whether we've been able to serve a version of a package and avoid doing the fallback if so.

Redirect to `/` if a given path doesn't exist

apm-serve currently tries to fetch content provided in a package.

For example, aragon.mainnet.aragonpm.com/manifest.json fetches the deployment manifest.json, but aragon.mainnet.aragonpm.com/organization may be a common typo and should at least redirect to the index.

Given that apm-serve is only serving as a gateway to frontends deployed on aragonPM, redirecting to / (to get the index.html, if one exists) is akin to what would need to happen with SPA-based routers anyway.

support arbitrary length hosts

The express-subdomain middleware needs to be able to calculate the subdomain for arbitrary length hosts like aragonpm.com or aragonpm-test.aragon.network. The default "subdomain offset" property for express is 2, this needs to be calculated dynamically based on the value of APMSERVE_HOST.
For background see:
bmullan91/express-subdomain#17
bmullan91/express-subdomain#17 (comment)
http://expressjs.com/en/4x/api.html#app.settings.table

Automate deployment

Create automated docker builds on merge with master

Brotli support

Support for Brotli recently landed in Node.js (11.7.0), and should be added to compression soon.

I’m opening this issue to remember to upgrade compression when the feature gets released, so we can start using it as soon as possible.

Move to apm.js repo?

Index page (aragonpm.com) for explaining what APM is

Make network subdomain the first one to ease certificate generation

Basically revert #3.

This will ease creating SSL certificates for aragonpm.com, as we can get wildcard certs for *.[network].aragonpm.com for all the networks that we support.

Update to latest node LTS

Enable gzip

See https://expressjs.com/en/advanced/best-practice-performance.html#use-gzip-compression