Use a lightweight server that dynamically renders HTML

[toolness]

I've alluded to this in other issues and discussions, but I wanted to document it here.

When I was originally asked to come up with a site prototype for #75, It seemed implicit that most of the site's content would be static (as opposed to user-generated). That was the assumption I relied on when building the initial prototype of the site, which generated a static website that could be uploaded to S3.

However, the next heartbeat, I saw the full teach site roadmap for the first time, and it included quite a bit of dynamic functionality powered by user-generated content, like mentor profiles. Because I had already started productionalizing the prototype and the v1 of the teach site was still going to be largely static content, I didn't propose to change the static site nature of the site.

However, now that we're on the cusp of releasing v1, I'd like to formally propose moving to a slightly different architecture whereby a lightweight server dynamically renders HTML for clients and aggressively caches it. Or, as mentioned in #579 (comment):

... I think we should evolve this site so it "gracefully degrades" into a standard web-1.0 style website, but transforms into a badass hovercapable 1962 Chevrolet Corvette if the user's browser is cool enough.

This will enable a number of use cases:

• Mentor profiles, clubs, and other user-generated content (UGC) can have their own clean URLs, e.g. /mentors/toolness, without needing to constantly regenerate the site every time a user adds/changes their content.
• UGC can be pre-loaded into the initial HTML sent to the user, improving initial page load experience.
• UGC could be easily viewed by users without JS enabled, as well as scraped by web spiders for SEO (if we want to allow that kind of thing).
• UGC could potentially be submitted by users without JS enabled.
• The site can potentially deliver different content for certain user agents (see Determine browser support #151 (comment)).
• Basic locale information will be easier to detect and respond to on the server-side.

Fortunately, because of the way we're currently generating the static site, this isn't actually a very hard thing to do. I was also talking to @jdotpz and there's a way we can still even use the generated static site as a fallback if the server goes down for some reason, or if we need to perform maintenance on it--that way, at least users will always be able to see the basic static content of the site.

Any thoughts on this approach are appreciated!

[rossbruniges]

All of these suggestions sound pretty good to me - dynamic UGC is something that's always a good candidate for post-loading, and can even give that impression of 'live-ness' as people quickly see that things are changing around them when viewing the site.

In regard to caching each page you're probably good going with once an hour, and depending on the size/scale of that task could reduce that to twice a day. The key point here is that you're providing ALL users regardless of the browser capability something and from that point you can 'progressively enhance' the experience up as far as feature detection of the features that you're looking to use allows you which is a subtle (but to me important) difference to graceful degregation as that way all users at least get something opposed to having things broken or inaccessible.

For me the important parts to consider with this approach are:

1. Define what content all users should see and have that renderable via the server
2. Define the features that you want to detect that'll provide the improved user experience for those using a platform that supports it
3. Enjoy using all the new cool stuff

If there is a suitable path this can go so far to not actually needing to provide different or alternative content for less feature rich devices or platforms as you've ensured that users with those are covered. Load as much or as little HTML in after that initial render and there is no diminished or broken looking functionality.

Always happy to chip in more - you know where to find me :)

[hannahkane]

Grooming notes:

• This should be a pre-req for user profiles or other major UGC
• Effort: building the cacheing infrastructure will be the difficult part (unexplored territory)
• Resources: will need devops support

[toolness]

Hmm, I've been watching a bit of Build an App with React and Ampersand and there's a 6-minute tutorial on deploying with Surge. Surge (http://surge.sh/) is a service that lets us do a little more than AWS with the kinds of URLs we're able to provide, which can help us solve some of the problems I mentioned at the top of this issue, though it won't help us get around the problem of supporting search engines and folks without JS.

Another sort-of similar but kind of weird thing we can do is use a custom error document with S3 to define a "catch-all" webpage to provide clean URLs, which is hilariously what accidentally happened with #785. There's lots of caveats with this, though, and to a large extent it just feels wrong.

Another potential solution is for us to use some CloudFront magic to provide catch-all web pages, which jbuck might be able to help us with.

[ldecoursy]

Note: this is a solution for when we want clean URLs for mentor profiles, and more dynamic content.

[ldecoursy]

@toolness to file individual issues for remaining work to do then close this ticket. Won't hit production for awhile.

[ldecoursy]

Just awaiting review from @mmmavis

[toolness]

Update: mavis finished with review, now it's up to me to file some follow-up issues and merge the PR.

[toolness]

Ok, I just created the new issues; they're all linked-to from the description in #936.