2022-12-29

Thinking about deployment

• Qu 1: what about doing SSR rather than all SSG especially for large sites?

  • For large sites incremental rebuild is expensive
  • Currently you have to build the flowershow app for each site we deploy

• Qu 2: How does cloudflare do nextjs SSR stuff?

  • Previously the answer was basically: you couldn't. You had to use workers.

  • Now there is start of more native support with NextJS v13 edge runtime https://blog.cloudflare.com/next-on-pages/ (24 Oct 22)

    • Or as docs state: https://developers.cloudflare.com/pages/framework-guides/deploy-a-nextjs-site/

      Cloudflare Pages supports full-stack Next.js projects which use the Edge RuntimeOpen external link or any projects which can be statically exportedOpen external link. The Edge Runtime allows applications to use server-side features such as Edge API RoutesOpen external link, server-side rendering (SSR) pages with getServerSideProps()Open external link and MiddlewareOpen external link.

Asides

• TinaCMS went v1.0 in November. Always liked it, though still not sure about it as a notes/content-layer. Why?
  • GraphQL as the API continues to strike me as a ?. Yes, it can be awesome, … and it is often overkill
    • Plus, i'm left with a bit of a black-box. I want the content layer to be as simple as possible.
  • Markdown stuff is a bit of a black-box (i suspect they use remark but they don't say): "When your markdown content is requested through Tina's API, Tina serves a parsed AST version of the content." … "Tina also provides a <TinaMarkdown> component, which renders your md or mdx component from the parsed AST."
    • This will be great … until it's not. I really want full control here … though i guess i can get the raw content myself.
    • You also have to provide all components used explicitly

Brainstorm re simplest thing for markdown ≥ website

What's the simplest thing you could build that would turn markdown / digital garden into a site?

flowershow publish

Rough ideas

• Store data in cloud (rather than do SSG b/c that does not scale well)
• run a classic server to render (that way only one app to update to render everything differently or with fixes)
  • issue of course is if you want custom react components … then this doesn't work
  • classic story: if you just want the standard setup then a product approach works well
  • if you want customization (or custom components, theming etc) then much harder

OMM = ORM for markdown

you have object relational mappers.

we want object markdown mappers. i.e. take markdown and give out an object.

Markdown documents are, well, documents so a document approach with flexible schema is recommended.

What do i want to do:

load path/to/content/folder > my-db

query (with sql) my-db

• Can add a schema (flexible to additional fields)
  • can validate if you like
• Can compute fields (on way in or way out)
• Can query this

What needs do we have?

• [global] Get a global table of contents (list of all pages?)
• Find me forward links for this page
• [global] Find me back links for this page
• Get page X
• Get all pages with attribute y
• [bonus] Search and especially full text search

[global] = it requires global computation (can't compute from a given page)

Simplest products one could build

• Data Pages (with no options for customization of look and feel, or components)
  • no customization ≥ can focus on building from data etc
• Flowershow no customization
• Markdown CMS: build the ORM for markdown
  • Push my markdown to a useful queryable structure
  • Push my assets somewhere convenient