Initial Tech Stack

[upsiflu]

I compared some potential components to assemble the initial pacha go infrastructure.

Goals:

• Fast to develop
• Easy to iterate on and try new features
• Welcoming for new and occasional developers and especially for Maia
• No unnecessary complexity
• No unnecessary weight and latency
• Each component can be replaced easily
• Prevent errors and hard-to-catch bugs

Needed Features:

• SSG
• Hosts can edit their ad (or Maia does it for them)
• Workers can send messages and apply to hosts
• Database should be accessible by admins so that they can delete or edit ads and messages in the worst case

Niceties:

• Full-text search
• Image optimization
• As few layers as possible

astro + astro-db/studio (drizzle + turso) on cloudflare

Good:

• Astro is popular and relatively easy for beginners and generally well-designed
• SQL database is the most expressive and flexible storage solution
• Mix any framework and rendering method (SPA with hydration, SSG, SSR) in islands <3
• Astro has good presets and doesn’t need as much reconfiguration as other ecosystems
• Generous resource limits for both turso/astro studio and cloudflare

Bad:

• A lot of infrastructure
• Relies on 2 commercial vendors
• Astro studio and astro-db are clearly beta and not well documented. We weren’t able to get all features to work.

Interesting:

• Astro is developing at a rapid pace and we see huge new features every day or so. Where will it go?

lamdera

Eliminates all glue code; serves an optimized SPA

Good:

• Extremely fast to develop and easy to iterate on
• Only one (great) language for all the code!
• Easy to learn
• No complexity at all
• Elm has a beautiful and generous community and high-quality, long-living packages
• For example that map package

Bad:

• Single Vendor Lock-in
• CMS functionality needs to be implemented in the client code (reading and writing images)
• SPA but no SSG / hydration
• Extremely limited resources

elm-pages + netlify + turso

Good:

• Modular
• SQL database is the most expressive and flexible storage solution
• SSG + SSR + hydrates into SPA
• SSR has access to embedded replica
• Generous resource limits for both turso and netlify
• Elm has a beautiful and generous community and high-quality, long-living packages, for example that map package

Bad:

• Several languages (Elm and either ts or sql)
• A lot of infrastructure
• Relies on 2 commercial vendors

Interesting:

• With Netlify Create, we might be able to offer a direct-manipulation WYSIWYG CMS

elm-pages + cloudflare + appwrite

Good:

• Modular
• SQL database
• SSG + SSR + hydrates into SPA
• Appwrite has by far the most welcoming community, user-friendliness and support
• Extremely generous resource limits in Appwrite, esp. for open source projects with 15 contributions (free PRO tier)
• Fastest CDN (Cloudflare)
• Elm has a beautiful and generous community and high-quality, long-living packages
• Complete type safety from data to pixel thanks to elm-graphql and elm-pages

Bad:

• Not a common stack: a lot of initial research and tryout before we have a running prototype
• Database is not near the SSG. If that’s a problem, we can do SSG on Appwrite instead of Cloudflare

[upsiflu]

Details for elm-pages + netlify + turso

• Host an Embedded Replica near the rest of the app to remove the hop latency for database reads in SSR
  • Configure both url and syncUrl in the app
  • Trigger client.sync() before reads that need to be in-sync