Skip to content

Instantly share code, notes, and snippets.

@kellpossible

kellpossible/Design.md

Last active February 4, 2023 02:51
Show Gist options
  • Save kellpossible/09fda6b44e39f3f670e04adea171dbbb to your computer and use it in GitHub Desktop.
Save kellpossible/09fda6b44e39f3f670e04adea171dbbb to your computer and use it in GitHub Desktop.
Download ZIP
Caucusus Avalanche Forecast PDF
Raw
Design.md

Caucusus Avalanche Forecast PDF Generation

Tool to create forecast html to print to PDF and share.

Product Research

Software Architecture

Goals:

  1. Simple and fast to create
  2. Reliable
  3. Cheap to deploy
  4. Easy to maintain
  5. Decent read performance

Option 1 - SSG

Forecasts are represented using hand edited data files and markdown.

Advantages:

  • Extremely quick to create entire website.
  • Can take advantage of CDN for excellent performance.
  • Lots of nice built-in functionality in Zola and I'm already familiar with it.
  • Auth model is simple (a non-issue).

Disadvantages:

  • Editing data files is not exactly user friendly for most people, nor is interacting with git.

An offline editor could be easily created which may alleviate some of these concerns, however is that much more work than just creating the app using SSR in the first place I wonder? Alternatively https://tina.io/ could also perhaps be deployed.

Option 2 - SSR

UI:

Backend:

Database: SQLite using one of:

Localization

Database Replication:

Database Backups:

GIS Sqlite

Markdown:

Advantages:

  • Maximum flexibility. Good if we want to support user observation submissions in the future.
  • Easy to build editor with validation.
  • Self contained, does not rely on any external infrastructure for hosting, deployment or editing.
  • Allows the use of Fluent for localization which gives us much more control.

Disadvantages:

  • Perhaps more complicated to deploy and maintain.
  • More complicated for someone else to pick up and work with in the future.

Option 3 - Elixir + Phoenix SSR/LiveView

Advantages:

  • Integrated tech stack, with a standard project structure.
  • Explore what developing with Phoenix is actually like.
  • A reputation for being extremely reliable.
  • Live view offers the possibility for live updates of things like: editing the report with formatting feedback, observations, comments.

Disadvantages:

  • I don't know Elixir or Phoenix.
  • It's less popular than Rust overall, and tools for doing things like GIS are more limited.
  • More complicated deployment, requires Erlang.
  • Elixir is a dynamically typed language, I don't like it for that reason alone. Could write some code using Gleam, but then we're in the mixed language domain.

Decision

All things considered, I think the option 2 will be better in the long run, it might be more work in the short term but it is more flexible, and it leads to a very nicely self contained solution that may be used by other avalanche forecasting organisations in the future (perhaps in Kamchatka, Nepal, Pakistan, India, China, etc). I will build it to be generic from the get-go, because making something just for Georgia seems like a bit of a waste when the need is much wider. This won't be the last time someone wants to set up an avalanche forecasting area. Of course this does risk increasing the scope of the project, but it's not my first project and I think it's totally manageable.

Phases

Phase 1 - PDF Reports

Start with a way to generate PDF reports. I don't care how. The reports need to look decent, but not perfect. Should be looking nice on the phone or laptop. PDFs are posted to the facebook group manually.

Phase 2 - Website

Website to view the reports, and download PDFs. Interactive forecast area map.

Phase 3 - User Submitted Observations

User can submit observations, these are available to be viewed on the map. We can use a Captcha and a basic avalanche question prompt to allow anyone to submit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment