@octamap/mondo-cli v1.0.1

Mondo CLI (BETA)

Imagine that you could create a SPA website (single page application) but with MULTIPLE PAGES!!!

• Someone opens www.your-website.com
  • We show the index.html
• Someone opens www.your-website.com/login
  • We show them login.html

Without the need of ANY JAVASCRIPT or expensive servers.

What? What does this mean?

• Every route (/login, /register etc) loads INSTANTLY!!
• You achive far better performance than using SSR, all while spending close to ZERO in hosting costs

How is this possible?

Subsite does the following to make this possible: 1. The Subsite Vite plugin: 1. Takes care of bundling your website upon calling (npm run build) in a way that exposes these routes on the top level of the dist folder 2. Sets up your development server during (npm run dev) so that you can navigate to your routes during development 3. Allows you to import scripts & styles relative to where your html files are located (for convenience) 2. The Subsite CLI does the following: 1. If you choose Cloudflare for hosting: 1. Initializes a (S3/R2) bucket on your cloudflare account 2. Connects the bucket to a domain on your cloudflare account 3. Uploads the build output from "npm run build" to the bucket 4. Creates rules on cloudflare that re-routes from your domain to the R2 bucket

How much will this cost?

• Cloudflare Rules is free
• Hosting files in a cloudflare bucket is the least expensive form of hosting anything. Its more or less impossible to find a way of hosting somthing in a less expensive manner

Technical Details on Rules (inner workings)

Localizations rewrite rule

Using subsite localizations in a html file will result in multiple different files in the file output after running "npm run build". One for each language

Project Structure

• login
  • login.html
  • localizations
    • sv.json
    • en.json
• index.html
• texts
  • sv.json <-- Swedish
  • en.json <-- English
• vite.config.ts
• package.json
• public
  • texts
    • sv.json
    • en.json
  • additional-content.html

vite.config.ts

export default defineConfig({
  plugins: [
    Subsite(() => ({
         "index": "/index.html"
       }), { defaultLanguage: "en"})
    ...

Build Output

• route <-- Data contains index.html
• route-sv <-- Data contains index.html (but with sv.json localizations)
• loginroute <-- Data contains login.html
• loginroute-sv <-- Data contains login.html (but with sv.json localizations)
• additional-content.html
• additional-content.html-sv

Subsite will then update then add these rules:

• Rule 1: Add language prefix if supported
  • So that we give the user a html file for their preferred locale
  • If:
    • (http.host wildcard "your-domain.com" and http.request.accepted_languages0 in {"sv"} and not http.request.uri.path contains ".")
  • Then rewrite path to:
    • concat(http.request.uri.path, "route", "-", http.request.accepted_languages0)
• Rule 2: Give "index.html" if invalid path
  • So that we still give html even when the user navigates to a somewhere that isnt supported
  • If:
    • (http.host wildcard "your-domain.com" and not http.request.uri.path contains "." and not starts_with(http.request.uri.path, "/login") and not http.request.uri.path eq "/")
  • Then rewrite path to:
    • concat(http.request.uri.path, "route")
• Rule 3: Add "route" prefix when language is default or unsupported
  • So that we give the html with the default localization when the user uses the default language or a unsupported language
  • If
    • (http.host wildcard "your-domain.com" and not http.request.accepted_languages0 in {"sv"} and not http.request.uri.path contains ".")
  • Then rewrite path to:
    • concat(http.request.uri.path, "route")
• Rule 4: Add "language code" prefix on .html files
  • So that localizations work on regular .html files
  • If
    • (http.host wildcard "your-domain.com" and http.request.accepted_languages0 in {"sv"} and http.request.uri.path in {"/additional-content.html"})
• Then rewrite path to:
  • concat(http.request.uri.path, "-", http.request.accepted_languages0)

This will result in:

• User has language "sv"
  • Calls to "your-domain.com" will go to "your-domain.com/route-sv" (thanks to rule 1)
  • Calls to "your-domain.com/login" will go to "your-domain.com/loginroute-sv" (thanks to rule 1)
  • Calls to "your-domain.com/example" will go to "your-domain.com/route" (thanks to rule 2)
• User has languge "el" (greek)
  • Calls to "your-domain.com" will got to "your-domain.com/route" (thanks to rule 3)