Hybrid Architecture (Serveless, Incremental, SSR)

[thescientist13]

Will need to flesh this out with more docs and diagrams, but just quickly want to get some initial thoughts and ideas down.

Overview

As part of the current Jamstack migration and eventual cutover as per #13 , the initial conceit is to just a lateral technology transition, where previously it was an Angular SPA, now it will just be a Lit SPA.

However, the content on the app is blend of static (artist and album details) and dynamic (posts and events) but everything is in a database, for content that hasn't changed in years and is so small. Some ideas to explore

• Move all artist and album content to markdown (or something like Netlify CMS?)
• Make all dynamic content (events and posts) serverless
• Maybe a bit overkill for this project, but would like content changes to not have to trigger and entire rebuild for a single content change (like ISG / SWR or DPR)
• AWS +arc.codes

Proposal

One thing that would be nice is that artist or album information would only have to be rebuilt if something with that artist changed. Basically, just because one artist adds a new album, doesn't mean every artist and album page needs to get rebuilt., so what does a hybrid Architecture docs and diagram (what does SSR actually look like re:bundled assets vs content ?)

Want to layout the docs and diagrams for this short (static + CMS ) all the way through long (serverless + CMS)

[thescientist13]

Overview

Ok, so now that SSR and static SSR prerendering is coming to Greenwood, its time to think about how we to re-architect the Analog Studios website. The current plan is roughly following this sequence and current status is as follows:

1. Phase 1: From SPA w/ Angular -> SPA w/ Greenwood + Lit
2. Phase 2: From SPA -> (mostly) SSG (in progress) - Jamstack + Hybrid Content Architecture (Phase 2) #13
3. Phase 3: From SSG -> Serverless Side Rendering (SSRLess)

Information Architecture

At a high level, I think the website can be broken down into two buckets of information:

• Content: Artist and album information, can / should always be static content. Ideally in markdown files in the repo.
• Data: Events and Posts, that could change often, are not so much set it and forget it, and often requires data be structured and validated against certain fields. This is a great use case for a CMS and most of the info here would just be a reposting of links and information to other sources like Facebook and YouTube.

There is another category that is probably a sibling to Data:

• Configuration: For example, a custom API that returns if a live stream is happening on the site so a special popup / modal can be shown. Likely coming from a CMS and in the form of a toggle.

I guess Posts could go both ways? Or maybe just leave it all to version control and just update in the HTML?

Workflow

Ideally, the data and content sources for the site should be optimized for a couple of things

1. Easy for me to add / edit and ideally all through a browser, e.g. GitHub for markdown, CMS for data, etc
2. Should be as close to HTML as possible to reduce work and maintenance just for shipping content to the user

Would like to confirm that can still use fancy things like TS if you want to, but nudge you down the direction of

Summary

Currently everything is stored in a DB in AWS and fetched over API calls in the browser, but in the move to be more static, here is the ideal information architecture.
Ide

Source	Format	Usage	Notes
Artists	Markdown	Build Time
Albums	Markdown	Build Time	Has to have 1:1 relationship with Artist
Events	CMS	Run Time	Over time, we may want this paginated only returning last, current, and next month data
Posts	HTML	Build Time
Config	CMS	Run Time

---

Taking this further, we could introduce rendering at the edge so as just bits of content are changed, Greenwood will only have to build one route at a time when needed based on a webhook from GitHub or the CMS.