Future of Flowershow - Rufus and Ola - 2023-04-11

Future of Flowershow - Rufus and Ola - 2023-04-11

Present: Rufus, Ola

🔴 https://drive.google.com/file/d/1jQYs-sC8OSKPAikWeMucYef8r0_3DsDP/view

Intention: discuss Vision for Flowershow going forward

Agenda

Insights from our experience with Flowershow over the last months

  • We have built 5 sites using Flowershow ourselves
  • We have 250 ⭐ and quite a few users?
  • On the sites we have built ourselves what have we found?
    • We wanted more a framework
      • Flowershow is useful as a bootstrap …
      • But also kind of annoying in other ways …
      • Has got better with v1 (monorepo)
      • But that was where we became a framework
    • At other end of spectrum: users (and our own use cases) where we want something ultra-simple that "just works" i.e. i don't have to do stuff myself (so less framework-y)

Insights 1: build a framework not a template

A framework is:

  • Useful library
  • Might have bootstrap template and/or scaffolding … but you are on your own after that
  • Some patterns
  • Docs ❗
  • NB: he more you provide the more you have to maintain

Specifically, Flowershow framework should be:

  • Content Layer aka MarkdownDB
  • Some helpful components in "headless" style
    • headless style = using tailwind with named color and heading etc
  • Markdown processing pipeline including combination of curate and/or bespoke plugins
  • Generally most useful thing is actually docs and patterns

Insight 2: if you go the product route, go cloud …

  • just want it to work
  • look good
  • (future: could have a plugin ecosystem)

This is simple and useful.

Flowershow Cloud

Design brainstorm

  • If you could get away with live rendering SSR … i would do it
    • Because you don't have to redeploy everyones's site on changes
    • You can do live updates (don't have to wait for 3m build to see your changes live)
      • You could even do live previewing by pushing to cloud and rendering from that in real-time
  • You have a defined set of components you can use
  • None of this complexity of using MDX …
    • At least not importing other files etc
    • Please make it work with ordinary html …
  • What do you need for SSR? you need a render pipeline that is not disk dependent
  • we need to push to the cloud …

MVP cloud.flowershow.app

User experience

  • signup / signin
  • I have my folder on disk:
    index.md
    cats.md
    cat.jpg # note need to render this direct
    
  • i do flowershow publish
  • and i have a site mysite-random.cloud.flowershow.app
  • Bonus: obsidian plugin

Architecture

How does it work:

  • sync to R2 somehow
  • and then i render …
  • more sophisticated stuff
    • i'm going to prep the sqlite database (or refresh it)
    • i'm going to do image processing etc

3 parts of the app: dashboard, render and sync

  • cloud dashboard
    • signup
    • billing etc
    • projects
  • render system
  • sync system
    • syncer to our storage
    • obsidian plugin

Next steps

  • Convert core to markdowndb and new next-mdx-remote render pipeline
  • Move the Flowershow repo to Datopian

Plan of work

  • SSR version of Flowershow
  • Library to load from r2
    • Work out how we do static assets e.g. do we rewrite or proxy or …
  • Test: Create an R2 folder or even github repo
  • Read subdomain incoming, look up project in project db, look up content from relevant r2 bucket
  • Profit

Uploader

  • Direct to R2 or through our gateway
  • How does permission work …
    • Need to hand out tokens to upload each file

Admin

  • Create a new "private" repo for flowershow-cloud on datopian

Notes

Questions

© 2025 All rights reservedBuilt with DataHub Cloud

Built with LogoDataHub Cloud