diff --git a/.gitignore b/.gitignore
index 2130136..2a35ca6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,17 +13,13 @@ lib-cov
# Coverage directory used by tools like istanbul
coverage
-# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
-.grunt
-
-# node-waf configuration
-.lock-wscript
-
# Compiled binary addons (https://nodejs.org/api/addons.html)
build/Release
# Dependency directory
-# https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git
node_modules
npm-debug.log
.eslintrc.js
+
+# en.wikipedia.org/wiki/.DS_Store
+.DS_Store
\ No newline at end of file
diff --git a/README.md b/README.md
index c04323a..77abf4d 100644
--- a/README.md
+++ b/README.md
@@ -2,63 +2,70 @@
# Technology Stack
-The software and systems we use to build the **`dwyl`** platform.
+The software and systems we use to build **`@dwyl`**.
-
+
+
+ Contents [click to expand]
+
- [Technology Stack](#technology-stack)
- [Why?](#why)
- [What?](#what)
- [The `PETAL` Stack](#the-petal-stack)
- - [**`Phoenix`**](#phoenix)
- - [`Phoenix` the "Most Loved" Framework in 2022](#phoenix-the-most-loved-framework-in-2022)
- - [**`Elixir`**](#elixir)
- - [`Elixir` is `#2` in 2022](#elixir-is-2-in-2022)
- - [**`Tailwind CSS`**](#tailwind-css)
- - [**`Alpine.js`**](#alpinejs)
- - [**`LiveView`**](#liveview)
- - [_Beginner_ Tutorials?](#beginner-tutorials)
- - [**`Phoenix`/`Elixir`**:](#phoenixelixir)
- - [Small Projects That Showcase `Phoenix`](#small-projects-that-showcase-phoenix)
- - [`Elixir` Utilities](#elixir-utilities)
- - [**`Flutter`**](#flutter)
- - [Miscellaneous](#miscellaneous)
- - [Our `MVP`](#our-mvp)
- - [Database?](#database)
- - [We _Prefer_ `PostgreSQL`](#we-prefer-postgresql)
- - [List of Organizations Using PostgreSQL](#list-of-organizations-using-postgresql)
- - [Operating System?](#operating-system)
- - [Continuous Integration](#continuous-integration)
- - [Deployment](#deployment)
- - [Application Server](#application-server)
- - [SSL/TLS Encryption](#ssltls-encryption)
+ - [**`Phoenix`** π¦βπ₯](#phoenix-)
+ - [`Phoenix` the "Most Loved" Framework β€οΈ](#phoenix-the-most-loved-framework-οΈ)
+ - [**`Elixir`** π§](#elixir-)
+ - [`Elixir` Remains Most Loved Language](#elixir-remains-most-loved-language)
+ - [`Tailwind CSS` π](#tailwind-css-)
+ - [`Alpine.js` (Optional) β¨](#alpinejs-optional-)
+ - [`LiveView` π](#liveview-)
+ - [_Beginner_ Tutorials? π°](#beginner-tutorials-)
+ - [`Phoenix` / `Elixir` π](#phoenix--elixir-)
+ - [_Small_ Apps That Showcase `Phoenix` π‘](#small-apps-that-showcase-phoenix-)
+ - [`Elixir` Utilities πͺ](#elixir-utilities-)
+ - [`Flutter` π±](#flutter-)
+ - [Miscellaneous π³](#miscellaneous-)
+ - [Our `MVP` π‘](#our-mvp-)
+ - [Database? ποΈ](#database-οΈ)
+ - [We _Prefer_ `PostgreSQL` π«Ά](#we-prefer-postgresql-)
+ - [Operating System? π§ ](#operating-system-)
+ - [Continuous Integration β
](#continuous-integration-)
+ - [Deployment π](#deployment-)
+ - [Application Server π’](#application-server-)
+ - [SSL/TLS Encryption π](#ssltls-encryption-)
- [tl;dr](#tldr)
- [Why Try a "New Stack"?](#why-try-a-new-stack)
- - [Why Try Something New When We're _Already_ Good with the "Old"...?](#why-try-something-new-when-were-already-good-with-the-old)
+ - [Why Try Something New When We're _Already_ Good with the "Old"...?](#why-try-something-new-when-were-already-good-with-the-old)
- [Making Difficult Decisions](#making-difficult-decisions)
- - [_Most_ "_Application Architects_" will pick one of these 3 options:](#most-application-architects-will-pick-one-of-these-3-options)
- - [Toast Knife Analogy](#toast-knife-analogy)
+ - [_Most_ "_Application Architects_" Pick One Of These 3 Options:](#most-application-architects-pick-one-of-these-3-options)
+ - [Toast Knife Analogy πͺ](#toast-knife-analogy-)
- [Focussing on Long-term Benefits](#focussing-on-long-term-benefits)
- [Further Reading on Long-term Thinking](#further-reading-on-long-term-thinking)
- - [*Contextualising* Technology Adoption (_Mini History Lesson_)](#contextualising-technology-adoption-mini-history-lesson)
- - [Does it _Scale_?!?](#does-it-scale)
+ - [_Contextualising_ Technology Adoption (_Mini History Lesson_)](#contextualising-technology-adoption-mini-history-lesson)
+ - [Does it _Scale_?](#does-it-scale)
- [What About _Full Stack `JavaScript`_?](#what-about-full-stack-javascript)
- [Alternative Databases?](#alternative-databases)
- [Radical Simplicity](#radical-simplicity)
- [Other Tech/Tools?](#other-techtools)
- [How to Propose `NEW` Tech/Tools?](#how-to-propose-new-techtools)
+- [Recommended Reading](#recommended-reading)
+
+
+
# Why?
-As a ***team of people***
-using technology
+As a ***team of people***
+using technology
to **_make_ digital products**,
it's _essential_ to **be _unambiguous_**
about the **stack/tools** we use,
-**so that _everyone_** is **clear**
-what we _all_ need to master.
+**so that _everyone_** is **clear**
+what we _all_ need to
+[**master**](https://www.google.com/search?q=definition+of+mastery).
> _If **anything** is **unclear** or you have **any questions** please_
-[***ask***](https://github.com/dwyl/technology-stack/issues).
+[**_ask_**](https://github.com/dwyl/technology-stack/issues).
+We are always happy to answer tech stack related questions.
+Please make sure you read the whole doc first.
# What?
-This document + diagrams _describe_
-the full "**`PETAL`**" Technology Stack
+This document + diagrams _describe_
+the full **`PETAL`** Technology Stack
we use for **`dwyl`** products/projects.
Each element in our stack was _carefully_ selected based
on its individual merits.
-When _assembled_ into a seamless "machine",
-the stack is _unrivaled_ for **developer productivity**
-and ***world-class quality***!
+When _assembled_ into a seamless machine,
+the stack is _unrivaled_ for **developer effectiveness**
+and _**world-class reliability**_!
## The `PETAL` Stack
-
+
+
-"PETAL" is an acronym1
+**`PETAL`** is an **acronym**
for the following elements:
-### **`Phoenix`**
-
-**`Phoenix`** is a Web Application Framework
-that does not compromise
-on speed, reliability or maintainability!
-**`Phoenix`** is the "_successor_"
-to the incredibly popular "Ruby-on-Rails" framework.
-Built _from scratch_ by highly experienced engineers
-who worked on/with Rails. It _solves_
-all of the speed/socket/scaling/concurrency, issues
+- **P**hoenix - the Web App framework
+ that **_organizes_ routes, schemas, controllers** and **tests _logically_**.
+- **E**lixir - the **functional** fault-tolerant **programming language**
+that is a _joy_ to work with.
+- **T**ailwind - the **interface library**
+for building **beautiful mobile-first** & **responsive web apps**
+that feel fast and are easy to extend.
+With hundreds of templates & examples.
+- **A**lpine.js - the **_tiny_ effects and enhancements `JavaScript` library**
+that loads fast and **progressively enhances** the **user experience**.
+This is **100% optional**, apps work fine without it.
+- **L**iveView - the system that **_significantly_ simplifies**
+creating interfaces that update in **real-time**
+whenever a change is made by anyone else.
+
+Let's go through each of these in a bit more detail.
+
+### **`Phoenix`** π¦βπ₯
+
+**`Phoenix`** is the Web Application Framework
+that **does not compromise**.
+
+**`Phoenix`** is the _successor_
+to the incredibly popular
+[Ruby-on-Rails](https://rubyonrails.org/)
+framework
+(commonly referred to as `Rails`).
+That was used by many startups and successful companies
+e.g: `AirBnB`, `GitHub`, `Shopify` and `Twitter`
+(most of which have migrated away from `Rails` for scalability reasons).
+
+**`Phoenix`** was built _from scratch_
+by highly experienced engineers
+who worked on/with `Rails`.
+It _solves_
+all of the speed/socket/scaling/concurrency issues
people felt when building/using Rails apps.
-The list of ***benefits*** Phoenix has over
+The list of _**benefits**_ `Phoenix` has over
(_virtually every_) other Web Frameworks is _extensive_.
-Please see:
+See:
[dwyl/**learn-phoenix-framework**#our-**top-10-reasons**-why-phoenix](https://github.com/dwyl/learn-phoenix-framework#our-top-10-reasons-why-phoenix)
-#### `Phoenix` the "Most Loved" Framework in 2022
+#### `Phoenix` the "Most Loved" Framework β€οΈ
-`Phoenix` tops the list of "Most Loved" Frameworks
-on the 2022 StackOverflow Community Survey β€οΈ
-
-https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies
+**`Phoenix`** tops the list of "**Most Loved**" Frameworks
+for the **3rd year in a row**
+on the
+[2025 StackOverflow Developer Survey](https://survey.stackoverflow.co/2025/technology#2-web-frameworks-and-technologies). β€οΈ
+https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies
-### **`Elixir`**
-
-**`Elixir`** is the _functional_ programming language
-used by the **`Phoenix`** framework.
-**`Elixir`** is a _beautiful_ language
-written _from scratch_ to be
-***friendly, concise and efficient***.
-***Yes***, `Elixir` not as
+This is not a
+[popularity contest](https://en.wikipedia.org/wiki/Popularity_contest);
+the votes are private/confidential.
+When software engineering community _collectively_
+votes that a framework is their "**most loved**",
+you know that they **_love_ using it**.
+
+### **`Elixir`** π§
+
+**`Elixir`** is the **_functional_ programming language**
+used by the **`Phoenix`** framework.
+**`Elixir`** is a **_beautiful_ language**
+written _from scratch_ to be
+**_friendly, concise and efficient_**.
+What this means is that you can write
+elegant expressive programs
+that achieve impressive results with fewer words.
+And because it's **functional** (with immutable data),
+it's considerably easier to follow the logic
+even when reading someone else's code
+or your own you're returning to after a few years.
+
+**_Yes_**, `Elixir` not as
["_mainstream_"](https://github.com/dwyl/learn-elixir/issues/102#issuecomment-1105416646)
-as `JavaScript`, `Java`, `C#` or `PHP`,
+as `JavaScript`, `Java`, `C#` or `Python`,
but the adoption is _growing rapidly_ and most importantly
-many _experienced_ developers are gravitating towards and
-describing it as their ["most wanted"](https://github.com/dwyl/the-book#you-will-learn-in-demand-tech-toolsskills)
+many **_experienced_ engineers** are gravitating towards and
+describing it as their
+["most wanted"](https://github.com/dwyl/learn-elixir/issues/102#issuecomment-3214201950)
Also a language's popularity has more
to do with the intellectual inertia people/companies have because
they allow existing (_legacy_) codebases to dictate future development;
i.e.
-[***sunk cost bias***](https://www.investopedia.com/terms/s/sunk-cost-trap.asp).
-see: [dwyl/**learn-elixir#key-advantages**](https://github.com/dwyl/learn-elixir#**key-advantages**)
+[_**sunk cost bias**_](https://www.investopedia.com/terms/s/sunk-cost-trap.asp).
+see:
+[dwyl/**learn-elixir#key-advantages**](https://github.com/dwyl/learn-elixir#key-advantages-)
-#### `Elixir` is `#2` in 2022
+#### `Elixir` Remains Most Loved Language
-`Elixir` is the 2nd
-"Most Loved" programming language:
+For the 3rd year running,
+`Elixir` is the 3rd
+"Most Loved" programming language in the world:
+[survey.stackoverflow.co/2025/technology/#2-programming-scripting](https://survey.stackoverflow.co/2025/technology/#2-programming-scripting-and-markup-languages)
-https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages
-This is a good measure of how much people _enjoy_ working
-in the language.
-And as we all know people who _enjoy_ their work
-are _better_ at doing it!
-### **`Tailwind CSS`**
+First appeared on:
+https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages
+
+This is a good measure
+of how much people _enjoy_ working
+in the language.
+And as we all know people who _enjoy_ their work
+are _better_ at doing it!
+
+> **Note**: The 2026 StackOverflow Survey
+> will be released later this year,
+> we will update this repo accordingly.
-**`Tailwind`** is the most _sane_ way
+### `Tailwind CSS` π
+
+**`Tailwind`** is the most _sane_ way
of creating a _beautiful_ web app UI
that can _easily_ be extended by a team of people
without fear of one person's change "_breaking_" another feature.
Unlike "_traditional_" CSS which - _as it's name implies_ - encourages
-"_cascading_" of styles, `Tailwind`
+"_cascading_" of styles, `Tailwind`
makes the style of each component _specific_
and _local_ to that component.
-see:
+see:
[dwyl/**learn-tailwind**](https://github.com/dwyl/learn-tailwind)
-### **`Alpine.js`**
+We paid for a license for
+**Tailwind Plus**:
+[tailwindcss.com/plus](https://tailwindcss.com/plus)
+It has hundreds of carefully crafted UI templates
+that can easily be customized.
+
+### `Alpine.js` (Optional) β¨
-**`Alpine.js`** is a lightweight library for enhancing interactions
-in a web application. It's declarative, responsive and easy to learn.
-`Alphine.js` plays well with `LiveView` for progressive enhancements.
-see:
+**`Alpine.js`** is a **lightweight** library
+for enhancing interactions in a web application.
+It's **declarative**, responsive and easy to learn.
+
+`Alphine.js` plays well with `LiveView` for
+[progressive enhancements](https://en.wikipedia.org/wiki/Progressive_enhancement).
+see:
[dwyl/**learn-alpine.js**](https://github.com/dwyl/learn-alpine.js)
-### **`LiveView`**
+`alpine.min.js @ 3.13.8` is `41 Kb` _uncompressed_.
+When delivered over a network (minified + gzipped),
+the size footprint drops down to roughly `14 KB`.
+
+This means it loads in under **`200ms`** (1/5 second)
+even on a slower **`3G`** connection.
+
+For a concrete example of how we are using `Alpine.js`,
+read:
+[`app.js`](https://github.com/dwyl/mvp/blob/main/assets/js/app.js)
+it handles the drag-and-drop and effects in the `MVP`.
+This is **_fully_ documented** in:
+[`/drag-and-drop.md`](https://github.com/dwyl/learn-alpine.js/blob/main/drag-and-drop.md)
+
+### `LiveView` π
**`LiveView`** is a radically simplified way
-of building realtime web apps with significantly less code.
+of building **realtime web apps**
+with **_significantly_ less code**.
+
+`Phoenix` + `LiveView` allows us
+to build rich interactive web apps
+with realtime reactive UI
+(no page refresh when data updates)
+without writing `JavaScript`!
+This enables building
+incredible interactive experiences
+in less time and
+with considerably less code.
+
+For more detail, on the "Why? What? How?" of `LiveView`,
+please see:
+[dwyl/phoenix-liveview-counter-tutorial#liveview](https://github.com/dwyl/phoenix-liveview-counter-tutorial/tree/764308bca4b23a1a1c55de12577d9b5cffd15d00#liveview)
+
+> **Note**: We only use `LiveView`
+> where **appropriate** to the **desired UI/UX**;
+> it's not a shiny object we _must_ use everywhere.
+> If live updates are **not needed**
+> e.g: in `Auth` or `Payment` flows
+> we use server-side rendered controllers
+> with _bare minimum_ client-side validation.
-## _Beginner_ Tutorials?
+## _Beginner_ Tutorials? π°
-We have _crafted_ a "***Complete Beginner's Guide***"
+We have _crafted_ a "**_Complete Beginner's_ Guide**"
for each element in the stack, so that we:
-+ ***Document our collective learning***
+
+1. **Document our collective learning**
`while` we are building projects.
-(_because as humans
-we **forget fast**
+(_because as humans
+we **forget fast**
unless we **capture** it **immediately**_!)
-+ ***Share*** our knowledge with other people so we can
- + Help to train (_potential_) new team members
- as quickly/effectively as possible.
- + ***Collectively iterate*** on our knowledge
- and "_level-up_" as a _team_!
- + "Onboard" the client team (_who may want/need_) to
- support/maintain the codebase/project
- if/when we _seamlessly_ "hand over".
- + Inform the wider community
- of both technical _and_ non-technical
- people ("stake holders") who are _generally_
- interested in _understanding_ the project.
- + Enlighten other teams/organisations/agencies/etc. we aren't in
- _direct_ contact with that there is a "_more fun_" way of building software!
-+ Make _everyone's_ life easier/better
+
+2. **_Share_** our knowledge with other people so we can:
+
+- Help to train (_potential_) new team members
+as quickly/effectively as possible.
+- **_Collectively iterate_** on our knowledge
+and "_level-up_" as a _team_!
+- "Onboard" the client team (_who may want/need_) to
+support/maintain the codebase/project
+if/when we _seamlessly_ "hand over".
+- Inform the wider community
+of both technical _and_ non-technical
+people ("stake holders") who are _generally_
+interested in _understanding_ the project.
+- Enlighten other teams/organizations/agencies/etc. we aren't in
+_direct_ contact with that there is a "_more fun_" way of building software!
+
+3. Make _everyone's_ life easier/better
by having a "launch pad" for
[_rapid_ learning](https://youtu.be/hOZnP4dZYK0 "Matrix Easter Egg ;-)")!
-We have written several **_beginner_ tutorials**
+We have written several **_beginner_ tutorials**
that span our technology stack
and tools we actively use in development.
-### **`Phoenix`/`Elixir`**:
+### `Phoenix` / `Elixir` π
-Here are a few of our learning repositories
-pertaining to `Phoenix` and `Phoenix Liveview`.
+A few of our learning repositories
+specific to `Phoenix` and `Phoenix Liveview`.
1. Learn `Elixir`:
[dwyl/learn-elixir](https://github.com/dwyl/learn-elixir)
2. Learn `Phoenix`:
[dwyl/learn-**phoenix**-framework](https://github.com/dwyl/learn-phoenix-framework)
-3. Counter (Liveview):
+3. Counter (`LiveView`):
[dwyl/phoenix-liveview-**counter**-tutorial](https://github.com/dwyl/phoenix-liveview-counter-tutorial)
-4. Todo List (Liveview):
+4. Chat (`Phoenix` + `Channels`):
+[dwyl/phoenix-**chat**-example](https://github.com/dwyl/phoenix-chat-example)
+5. Todo List (`LiveView`):
[dwyl/phoenix-liveview-**todo-list**-tutorial](https://github.com/dwyl/phoenix-liveview-todo-list-tutorial)
-5. Stopwatch (Liveview):
+6. Stopwatch (`LiveView`):
[dwyl/phoenix-liveview-**stopwatch**](https://github.com/dwyl/phoenix-liveview-stopwatch)
-6. Chat:
-[dwyl/phoenix-**chat**-example](https://github.com/dwyl/phoenix-chat-example)
-7. Chat (Liveview):
+7. Chat (`LiveView`):
[dwyl/phoenix-**liveview-chat**-example](https://github.com/dwyl/phoenix-liveview-chat-example)
-8. Realtime cursor tracking (Liveview):
-[dwyl/phoenix-liveview-realtime-**cursor**-tracking-tutorial](dwyl/phoenix-liveview-realtime-cursor-tracking-tutorial)
+8. Realtime cursor tracking (`LiveView`):
+[dwyl/phoenix-liveview-realtime-**cursor**-tracking-tutorial](https://github.com/dwyl/phoenix-liveview-realtime-cursor-tracking-tutorial)
9. `Papertrail` and `Phoenix`:
[dwyl/phoenix-**papertrail**-demo](https://github.com/dwyl/phoenix-papertrail-demo)
10. `Flutter` and `Phoenix`:
[dwyl/**flutter-phoenix**-channels-demo](https://github.com/dwyl/flutter-phoenix-channels-demo)
-
-#### Small Projects That Showcase `Phoenix`
+### _Small_ Apps That Showcase `Phoenix` π‘
We have a couple of "internal" (but Open Source) projects
-that use `Phoenix`
+that use `Phoenix`
and serve as a good showcase for the stack:
-1. Labels:
-[dwyl/**labels**](https://github.com/dwyl/labels)
-2. Hits:
-[dwyl/**hits**](https://github.com/dwyl/hits)
-
-#### `Elixir` Utilities
-
-1. Useful:
-[dwyl/**useful**](https://github.com/dwyl/useful) - utility library.
-2. Content:
-[dwyl/**content**](https://github.com/dwyl/content) - content negotiation.
-
-### **`Flutter`**
-
-In this section you will find learning repositories
-where you can learn `Flutter`
-*and* how to use it with other technologies.
+1. Hits:
+ [dwyl/**hits**](https://github.com/dwyl/hits) π
+2. Image Uploads:
+ [dwyl/**imgup**](https://github.com/dwyl/imgup) πΌοΈ
+3. Labels:
+ [dwyl/**labels**](https://github.com/dwyl/labels) π·οΈ
+
+### `Elixir` Utilities πͺ
+
+Along our journey building apps for clients and ourselves,
+we've created a few reusable packages:
+
+1. `fields`:
+ [dwyl/**fields**](https://github.com/dwyl/useful) -
+ field definitions
+ with validation and transparent encryption/decryption.
+2. `useful`:
+ [dwyl/**useful**](https://github.com/dwyl/useful) -
+ utility library.
+3. `content`:
+ [dwyl/**content**](https://github.com/dwyl/content) -
+ content negotiation.
+4. `link`:
+ [dwyl/**link**](https://github.com/dwyl/link) -
+ parse, shorten and format links.
+5. `auth_plug`:
+ [dwyl/**auth_plug**](https://github.com/dwyl/auth_plug) -
+ seamlessly add authentication to any Phoenix App.
+
+All the code we write is extensively documented,
+comprehensively tested and regularly maintained (where required).
+One of the many beauties of `Elixir` code
+is that it requires _very_ low maintenance;
+it just keeps working year after year.
+
+### `Flutter` π±
+
+We are using `Flutter` for our **Native Mobile App**.
+See: [`/flutter.md`](https://github.com/dwyl/technology-stack/blob/main/flutter.md)
+
+Along the way
+we've created several learning resources for `Flutter`
+and how to use it with other technologies:
1. Learn `Flutter`:
[dwyl/learn-**flutter**](https://github.com/dwyl/learn-flutter)
-2. Learn `Dart`:
+1. Learn `Dart`:
[dwyl/learn-**dart**](https://github.com/dwyl/learn-dart)
-3. `Supabase` and `Flutter`:
-[dwyl/**supabase**-flutter-demo](https://github.com/dwyl/supabase-flutter-demo)
-4. Counter:
+1. Counter:
[dwyl/flutter-**counter**-example](https://github.com/dwyl/flutter-counter-example)
-5. Stopwatch:
+1. Stopwatch:
[dwyl/flutter-**stopwatch**-tutorial](https://github.com/dwyl/flutter-stopwatch-tutorial)
-6. Todo list:
+1. Todo list:
[dwyl/flutter-**todo-list**-tutorial](https://github.com/dwyl/flutter-todo-list-tutorial)
-7. `Bloc`:
+1. `Bloc`:
[dwyl/flutter-**bloc**-tutorial](https://github.com/dwyl/flutter-bloc-tutorial)
+1. `Supabase` and `Flutter`:
+[dwyl/**supabase**-flutter-demo](https://github.com/dwyl/supabase-flutter-demo)
-
-### Miscellaneous
+### Miscellaneous π³
In this section,
we will list a few repos that explain
concepts and tools that we are actively using
while developing our [`app`](https://github.com/dwyl/app).
-
1. Payment processing:
[dwyl/learn-**payment-processing**](https://github.com/dwyl/learn-payment-processing)
1. API design:
@@ -291,45 +431,51 @@ while developing our [`app`](https://github.com/dwyl/app).
1. `Github Pages` deployment:
[dwyl/learn-**github-pages**](https://github.com/dwyl/learn-github-pages)
+### Our `MVP` π‘
-### Our `MVP`
-
-We have built a fully working MVP version of our App!
+We have built a working MVP version of our App!
Check it out at
-[dwyl/**mvp**](https://github.com/dwyl/mvp)!
-
-
-## Database?
-
-The _reason_ we do not _specify_ our Database
-in the "PETAL" Acronym is
-that **`Phoenix`** allows us
-to use **_any_ Relational Database**.
-
-By _abstracting_ the data layer using "Ecto" the application is "_decoupled_"
+[dwyl/**mvp**](https://github.com/dwyl/mvp)! π±
+
+## Database? ποΈ
+
+The _reason_ we do not _specify_ our Database
+in the `PETAL` acronym is
+that **`Phoenix`** abstracts its'
+database access via
+[`Ecto`](https://phoenix.hexdocs.pm/ecto.html)
+to provide built-in support
+to the following **databases**:
+
+* `PostgreSQL` (via [`postgrex`](https://github.com/elixir-ecto/postgrex))
+* `MySQL` (via [`myxql`](https://github.com/elixir-ecto/myxql))
+* `MSSQL` (via [`tds`](https://github.com/livehelpnow/tds))
+* `ETS` (via [`etso`](https://github.com/evadne/etso))
+* `SQLite3` (via [`ecto_sqlite3`](https://github.com/elixir-sqlite/ecto_sqlite3))
+
+By _abstracting_ the data layer
+using `Ecto` the application is "_decoupled_"
from the database.
-This means that if a client _asks_ us to deploy to MySQL or
-Microsoft SQL Server
+This means that if a client _asks_ us to deploy to `MySQL` or
+`Microsoft SQL Server`
(_e.g. because they already have in-house capability
for maintaining one of these databases_)
-we can easily accommodate that
+we can _easily_ accommodate that
without re-writing _any_ of the `Phoenix` app!
+Changing a couple of lines of configuration
+is all that is needed.
-### We _Prefer_ `PostgreSQL`
+### We _Prefer_ `PostgreSQL` π«Ά
-![postgres logo]()
-
-Our "_standard_" (_preference_) @dwyl is for `Postgres`.
-see:
-[dwyl/**learn-postgresql**](https://github.com/dwyl/learn-postgresql)
+Our "_standard_" (_preferred_) DB @dwyl is `Postgres`.
+see:
+[dwyl/**learn-postgresql**](https://github.com/dwyl/learn-postgresql) π
-Postgres is the most "_mature_" Open Source Relational Database.
-It's ***100% Free*** (_including all **"advanced"** features_)
-and has been deployed and ***battle-tested*** in ***every*** environment
+`Postgres` is the most "_mature_" Open Source Relational Database.
+It's **_100% Free_** (_including all "**advanced**" features_)
+and has been deployed and **_battle-tested_** in **_every_** environment
from `AWS` to "Bare Metal" and `Google Cloud` to `Microsoft Azure`!
-
> _**Many** well-known/successful apps rely
on `Postgres` as their `main` database_.
> _**NOT** that you should adopt a particular technology
@@ -337,109 +483,143 @@ based on who `else` is using it,_
> _but it's **good to know** that **plenty** of teams
are getting **excellent results** with `Postgres`!_
-##### [List of Organizations Using PostgreSQL](https://github.com/dwyl/learn-postgresql/issues/31)
+See:
+[List of Organizations Using PostgreSQL](https://github.com/dwyl/learn-postgresql/issues/31)
We have used _most_ of the "_popular_" Relational Databases.
-e.g: `MySQL`, `Microsoft SQL Server`,
-`Oracle` and `Aurora`, etc;
+e.g: `MySQL`, `Microsoft SQL Server`,
+`Oracle` and `Aurora`, etc;
all
[RDBMS](https://en.wikipedia.org/wiki/Relational_database_management_system)
have their pros/cons.
-The ***reason*** we like/use **`Postgres`**
-is because the ***community*** is _superb_.
+The **_reason_** we like/use **`Postgres`**
+is because the **_community_** is _superb_.
There is a great "_bank_" of _answered_ questions on
-[StackOverflow](https://stackoverflow.com/questions/tagged/postgresql)
+[StackOverflow](https://stackoverflow.com/questions/tagged/postgresql?tab=Votes)
and new questions get answered _fast_.
-## Operating System?
-A _"traditional"_
+From 2023 to 2025 `Postgres` has remained
+the **most used** and **most desired** Database:
+[survey.stackoverflow.co/2025/technology#2-databases](https://survey.stackoverflow.co/2025/technology#2-databases)
+46.5% of respondants use `Postgres`
+more than double `MySQL` (20.5%).
+
+## Operating System? π§
+
+A _"traditional"_
[**LAMP** stack](https://en.wikipedia.org/wiki/LAMP_(software_bundle))
includes the **Linux** Operating System
in the _name_.
-The "**PETAL**" stack runs
+The "**PETAL**" stack runs
on _any_ (_desktop/server_) Operating System
and can be deployed to any "_cloud_" infrastructure provider.
-While we have a _strong_ preference
-for `Unix` (e.g. `FreeBSD`) or
+While we have a _strong_ preference
+for `Unix` (e.g. `OpenBSD`) or
`Linux` (_e.g. `Ubuntu` or `CentOS`_) we know that
_both_ `Phoenix` and `Postgres` run
on almost _any_ environment including
Microsoft Windows Desktop & Server.
+We typically deploy our `Phoenix` Apps using `Ubuntu` + `Docker`.
-## Continuous Integration
+## Continuous Integration β
-We are using `GitHub` actions
-for Continuous Integration /
-Continuous Deployment.
+We are using
+[`GitHub` actions](https://docs.github.com/en/actions/get-started/continuous-integration)
+for
+[Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration)
+&
+[Deployment/Delivery](https://en.wikipedia.org/wiki/Continuous_deployment).
+It's **free**/included with `GitHub`
+and easily meets our needs.
For an example of this,
including automatic deployment to **Fly.io**
-see:
+see:
[`.github/workflows/ci.yml`](https://github.com/dwyl/mvp/blob/main/.github/workflows/ci.yml)
-## Deployment
+We have used other continuous integration platforms in the past
+and at the request of clients,
+e.g:
+[`GitLab`](https://docs.gitlab.com/ci/),
+[`Travis-CI`](https://www.travis-ci.com/),
+[`Circle-CI`](https://circleci.com/)
+or self-hosted `Jenkins`.
+We can easily adapt to the needs of the project.
+
+## Deployment π
We make a point of deploying our work as _soon_ as
-there is _something_ worth showing
+there is _something_ worth showing
to the target audience of "_end users_"
-so that we can get ***feedback*** as early as possible.
+so that we can get **_feedback_** as early as possible.
-Lately we have been using
+Lately we have been using
[**Fly.io**](https://github.com/dwyl/learn-devops/issues/72#issuecomment-917442712)
for deploying our Apps.
The experience is superb. β€οΈ
-#### Application Server
+We have used every major Cloud infrastructure provider
+over the last nearly 2 decades
+starting with `AWS` in 2009.
+Over the years we have captured much of our knowledge
+`public` repos e.g:
+[dwyl/**learn-devops**](https://github.com/dwyl/learn-devops)
+and
+[dwyl/**learn-aws-lambda**](https://github.com/dwyl/learn-aws-lambda)
+
+Many people have found our notes helpful.
+
+## Application Server π’
-The Phoenix Application Server is hosted on (_a minimum of_)
-Two Linux Servers.
+The `Phoenix` Application Server is hosted on (_a minimum of_)
+**Two Servers**.
(_often many more which send **messages**
one another to distribute load as a cluster_).
The "_cluster_" is managed by Erlang's "Supervisor".
-The Erlang Supervisor
+The
+[Erlang Supervisor](https://learnyousomeerlang.com/supervisors)
is the "_Gold Standard_" in infrastructure management,
-having been used by Telecoms companies
+having been used by Telecoms companies
for over 20 years in production
-with some Telcos reporting 99.9999999%
+with some Telcos reporting 99.9999999%
("_nine nines_") of "_up-time_".
> It's _far_ more likely that the _infrastructure_ provider (_e.g. AWS/Azure_)
will have a fault in their network/datacenter than an Erlang server "crashing".
+An individual request/process may crash but never the whole server.
-#### SSL/TLS Encryption
+## SSL/TLS Encryption π
All communication is over secure/encrypted channel
(_by default at all times_)
to protect the data/privacy
of people using the applications we make.
-We recommend using the "Let's Encrypt" service for SSL Certificates
-it's ***100% Free*** (and _provided by a Non-Profit foundation_)
+We recommend using the **Let's Encrypt** service for SSL Certificates
+it's **_100% Free_**
+(and _provided by a Non-Profit foundation_)
to help you get started, we wrote a
-***step-by-step setup guide*** for apps deployed to Heroku:
-[SSL-certificate-step-by-step-setup-instructions.md](https://github.com/dwyl/learn-heroku/blob/master/SSL-certificate-step-by-step-setup-instructions.md)
-
-
+**_step-by-step setup guide_** for apps deployed to any infrastructure:
+[/letsencrypt-wildcard-certificate.md](https://github.com/dwyl/learn-devops/blob/main/nginx/letsencrypt-wildcard-certificate.md)
-
-# tl;dr
+# tl;dr
There is _no shortage_ of options available for
-Technology Stack!
-See: https://www.google.com/search?q=technology+stack&tbm=isch
+Technology Stack!
+See:
+[google.com/search?q=technology+stack](https://www.google.com/search?q=technology+stack&tbm=isch)
So, _how_ did we _arrive_ at the conclusion that `PETAL`
was "_the **one**_" for us...?
We _already_ had a _really_ good
[Node.js Stack](https://github.com/dwyl/technology-stack/blob/main/legacy)
which worked well for us and our clients. so . . .
-
## Why Try a "New Stack"?
-#### Why Try Something New When We're _Already_ Good with the "Old"...?
+### Why Try Something New When We're _Already_ Good with the "Old"...?
Our _reasoning_ for
_considering_ an alternative approach/stack for building web apps
@@ -457,14 +637,14 @@ and
> LIFE Magazine (2 May 1955) p. 64β
-->
-In November 2016 we (_once again_)
+In November 2016 we (_once again_)
**questioned our _assumptions_**,
-***re-examined*** and
-[***surveyed***](https://github.com/dwyl/learn-elm/issues/10)
+**_re-examined_** and
+[**_surveyed_**](https://github.com/dwyl/learn-elm/issues/10)
the "landscape" of "_emerging trends_" in web app development.
-We were ~~pleasantly surprised~~ ***delighted*** to see the _amazing progress_
+We were ~~pleasantly surprised~~ **_delighted_** to see the _amazing progress_
made by the people in the `Elixir` / `Phoenix` community!
-Please see:
+Please see:
[dwyl/learn-phoenix-framework#**questions**](https://github.com/dwyl/learn-phoenix-framework#questions)
## Making Difficult Decisions
@@ -474,15 +654,15 @@ which technologies and tools you will use
to deliver the desired solution/benefit to the "_end users_".
Most people have the Tech/Tools decision made _for_ them
-by the company/organisation/boss they work for
-(_e.g: `Java` -> `Spring`,
-`Ruby` -> `Rails`
+by the company/organization/boss they work for
+(_e.g: `Java` -> `Spring`,
+`Ruby` -> `Rails`
or `PHP` -> `WordPress` or `Laravel`, etc._)
-This is because most companies
+This is because most companies
_already_ have an _existing_ app in "production",
which you have been hired to extend.
-Occasionally you will get the chance
+Occasionally you will get the chance
to build an app from "_scratch_"
however _most_ of the time someone `else` (_the "Architect"_)
will make the decision for what "_stack_" to use on your behalf,
@@ -493,38 +673,39 @@ trends and investigated the "_new and promising_" technologies
e.g: Stack Overflow
["Most Wanted" list](https://github.com/dwyl/the-book#most-wanted-programming-languages).
+### _Most_ "_Application Architects_" Pick One Of These 3 Options:
-#### _Most_ "_Application Architects_" will pick one of these 3 options:
-
-1. ***Go with what you (already) know***, use _existing_ stack
+1. **_Stick with what you (already) know_**, use _existing_ stack
with a minor variation because it's "easy to deploy" with
the existing infrastructure and will not get questioned by the "Executives",
DevOps team or "Compliance" department. This is the easy choice
and nobody ever got "_fired_" for sticking with what they know "_works_".
-2. Buy the whizz-bang all-in-one solution sold to them by the "Consultant"
-from "Big Vendor XYZ" (_outsource the thinking to a sales person who last
- wrote code in the 90's ... seems like a great idea ... NOT!_)
+2. Buy the whizz-bang all-in-one solution sold to them by the "**Consultant**"
+from "**Big Vendor XYZ**";
+this can _feel_ like a safe option,
+but it results in
+[vendor lock-in](https://en.wikipedia.org/wiki/Vendor_lock-in).
-3. Be "Bold" and try "***Popular Framework XYZ***"
+3. **Be Bold** and try "**_Popular Framework XYZ_**"
and hire an _external_
-team to build the new magic app.
+team to build the new magic app.
Then attempt to "_up-skill_" the _internal_
team to _maintain_ the code written by the consultants.
-None of these choices is _optimal_,
+None of these choices is _optimal_,
all have different levels of risk/reward.
-The "_hardest_" choice to make
+The "_hardest_" choice to make
is the one where you try something _totally_ different.
The _reality_ is that very few people
-have the time/resources/mindset/inclination
+have the time/resources/mindset/inclination
to take a step back
-and open their minds
-to the idea that there _might_
-be a "_better tool_" for the job
+and open their minds
+to the idea that there _might_
+be a "_better tool_" for the job
than the one they are _currently_ using.
-### Toast Knife Analogy
+### Toast Knife Analogy πͺ
Imagine Want to Make Yourself Some **Toast**.
The "_user story_" for this would be:
@@ -537,7 +718,7 @@ The "_user story_" for this would be:
to reduce the options for solutions for simplicity
i.e. not baking from scratch!_ )
-The "_traditional_" way to "_solve_"
+The "_traditional_" way to "_solve_"
the challenge of making toast:
1. Cut bread with bread knife
@@ -545,27 +726,26 @@ the challenge of making toast:
3. Turn on toaster for pre-determined amount of time
4. Wait patiently for toaster to make toast
-
But ... what if instead the "_old_" way we just described,
-someone invented a way
+someone invented a way
to _toast_ the bread `while` slicing it...?!
-Simply by using the "***New Tool***" for the job -
+Simply by using the "**_New Tool_**" for the job -
_in this case the
-["**Toast Knife**"](https://youtu.be/3ttzWuaPGMo?t=1m1s)_ -
+["**Toast Knife**"](https://youtu.be/3ttzWuaPGMo?t=1m1s)_ -
you can
-simplify the process to a ***single step***!
+simplify the process to a **_single step_**!
This is the power of being _open_ to considering "New" Tools/Technologies!
-Get the ***same result*** in **fewer** than half the "**steps**"!
+Get the **_same result_** in **fewer** than half the "**steps**"!
### Focussing on Long-term Benefits
The _short-term_ cost of learning a new stack
(_programming language or framework_) is time,
-We contend that the 1 week learning time
+We contend that the 1 week learning time
(_depending on the focus of learners_)
will pay for itself within 1 month
(_often sooner if the team is large/distributed because the **structure**
@@ -574,22 +754,22 @@ will pay for itself within 1 month
#### Further Reading on Long-term Thinking
-+ https://hbr.org/2012/08/thinking-long-term-in-a-short
-+ https://hbr.org/2011/03/capitalism-for-the-long-term
+- https://hbr.org/2012/08/thinking-long-term-in-a-short
+- https://hbr.org/2011/03/capitalism-for-the-long-term
-### *Contextualising* Technology Adoption (_Mini History Lesson_)
+### _Contextualising_ Technology Adoption (_Mini History Lesson_)
In **1996** Nokia introduced the
-["***Communicator***"](https://en.wikipedia.org/wiki/Nokia_Communicator)
+["**Communicator**"](https://en.wikipedia.org/wiki/Nokia_Communicator)
and was a **_incredible_ revolutionary innovation**!
-**Internet, Email and _Fax_** in your ***Pocket***!!
+**Internet, Email and _Fax_** in your **_Pocket_**!!
Nokia continued to _dominate_ the mobile phone industry/market for the next
-***decade*** producing the _best-selling_
+**decade** producing the _best-selling_
[**5110**](https://en.wikipedia.org/wiki/Nokia_5110)
-and
+and
[**3310**](https://en.wikipedia.org/wiki/Nokia_3310)
some of us are old enough to remember!
But by being "_ahead_" Nokia was _unable_ to see the "_contender_"
@@ -597,17 +777,19 @@ coming "_out of nowhere_" to challenge their position.
In 2006 _nobody_ was making/buying "smart" mobile phones
with glass touch screens that ran "apps" ...
-in
+in
[January 2007 Steve Jobs introduced the iPhone](https://www.youtube.com/results?search_query=Steve+Jobs+iPhone+Introduction+2007)
and _literally_ changed the industry!
The dominant/incumbent mobile phone maker **Nokia** had
-[***49% market share in 2007***](https://www.bbc.co.uk/news/technology-23947212)
+[**_49% market share_ in 2007**](https://www.bbc.co.uk/news/technology-23947212)
_mocked_ Apple's lack of features, poor battery life and high price.
-By 2013 Nokia had 3% Market Share (_for new device sales_) and was sold off "for parts" to Microsoft
-while Apple was the [most valuable company](https://www.statista.com/statistics/263264/top-companies-in-the-world-by-market-value/)
+By 2013 Nokia had **3% Market Share** (_for new device sales_)
+and was sold off "for parts" to Microsoft
+while Apple became the
+[most valuable company](https://www.statista.com/statistics/263264/top-companies-in-the-world-by-market-value/)
in history!
> _Many **people still buy** "**feature phones**"
@@ -627,7 +809,7 @@ but if you can **inexpensively switch**
to something **demonstrably better** in **every aspect**,
why would you stick with the "feature phone" of web frameworks...?_
_It's like taking the Bus to work when there's a perfectly
-good teleporter right next to the bus stop!! Madness._
+good **teleporter** right next to the bus stop!! Madness._
We are not _suggesting_ that _everyone_
is going to _suddenly_ flock to the "**PETAL**" stack
@@ -642,48 +824,86 @@ moving one framework to another is a _much_ more difficult decision.
But one thing is for _sure_ we are going to use the "_smart phone_"
even if other people insist on using the "brick".
+### Does it _Scale_?
-### Does it _Scale_?!?
-
-If you are new to web development,
-_please focus on **`UX`**
-and forget about "**scale**"_!
-
-> _Unless you work somewhere that
- **already** has "**millions of users**" and
-your team **cannot consider** anything that
-does not support a million concurrent connections...!_
-
-> _But let's face it, **most** people have
-[**imaginary scaling issues**](https://twitter.com/ThePracticalDev/status/800752571497545729)
-not **real** ones.
-discussing "scalability" **`before`**
-you have **10,000 paying customers**
-is a waste of time!!_
-
-Stop worrying about "scalability"
-and instead **focus** on building something **useful**
-**focus** on **User Experience** not ("backend") **scalability**!
-
-The _good_ news is that
-**`Phoenix`** "***scales***" _really well_!
-see:
+The _good_ news is that
+**`Phoenix`** "**_scales_**" **_really well_**!
+see:
[phoenixframework.org/blog/the-road-to-2-million-websocket-connections](https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections)
-Forget about "_scaling_" until you have _made_
-[***something people want***](http://paulgraham.com/good.html)
-and are _paying_ for!
-Then _use_ the pile of cash you got from your product
-to hire "_engineers_" to make it _available_ to more people!!
+This post was published in **`2015`**
+and was one of the catlysts
+that made us pay attention to `Elixir` and `Phoenix`.
+We had been building apps with `Node.js`
+(what we refer to as our "[legacy stack](/legacy)")
+since `2009` and deployment/scalability was always a chore.
+Seeing that a **single `Phoenix` server**
+could handle **2 Million Concurrent Connections**
+was an eye-opener that made us immediately **try** `Elixir`.
+
+Highly recommend watching Joe Armstrong's talk
+for a balanced primer on scalability:
+"Systems that run forever self-heal and scale":
+[youtu.be/cNICGEwmXLU](https://youtu.be/cNICGEwmXLU)
+
+
+Yes, scalability and especially **fault tolerance** is **important**.
+And **`Phoenix`** has your back with all of the above.
+It lets you **focus** on **User Experience**
+and rest assured that **scalability** is **baked-in**.
+
+If you are new to building web apps,
+_please focus on **`UX`**
+and **forget** about "**scale**"_!
+
+Focus **all** of your energy on crafting
+beautifully functional UI/UX
+that gives the person _using_ your App
+their desired outcome
+in as few steps as possible.
+
+The sad reality is that
+[most startups fail](https://briskfab.com/why-most-startups-fail-before-product-market-fit-and-how-to-avoid-it)
+before they achieve
+[product-market fit](https://en.wikipedia.org/wiki/Product-market_fit).
+Of those that "make it",
+most will end up re-building their App(s)
+as they refine the UX over time.
+
+So **focus on moving _fast_** and **building well-tested features**.
+
+> Unless you work somewhere that
+ **already** has **millions of users**
+ (e.g. [Big Tech](https://en.wikipedia.org/wiki/Big_Tech))
+ and your team **cannot _consider_** anything that
+ does not support a million concurrent connections ...
+> **_Most_** people have
+ [**_imaginary_ scaling issues**](https://x.com/ThePracticalDev/status/800752571497545729)
+ not **real** ones.
+discussing "scalability" **`before`**
+you have **100K paying customers**
+is a waste of time!!
+
+Stop wasting your time worrying about "scalability"
+and instead **focus** on building the **useful** features
+that people are requesting.
+
+Forget about "_scaling_" until you have
+[**_made_ something people want**](https://paulgraham.com/good.html)
+and are _paying_ for to solve their immediate pain!
+Once you have a few thousand paying "users",
+_use_ the pile of cash you got from your product
+to hire _experienced engineers_
+to make it _available_ to more people!
-
+
### What About _Full Stack `JavaScript`_?
-We still think that
-"***Full Stack `JavaScript`***"
-is a ***compelling proposition***
+We still think that
+"**Full Stack `JavaScript`**"
+is a **_compelling_ proposition**
_especially_ for people who are just starting out!
It allows you to write _one_ programming language
-on both the client and server; we get it!
+on both the client and server; we _get_ it!
However we have learned from years of experience
that it requires **a _lot_ more code and _maintenance_**
than **`PETAL`** for an **_inferior_ result**
@@ -745,34 +964,46 @@ in terms of UX/performance and developer productivity.
If we were to _consider_ an alternative to `SQL`, we
would use `RethinkDB`:
-https://rethinkdb.com
+[rethinkdb.com](https://rethinkdb.com)
But we are _relieved_ that the `Phoenix` team
-is _focussed_ on PostgreSQL because that _eliminates_
+is _focussed_ on `Postgres` because that _eliminates_
the "ambiguity" or "discussion" of "_which database_" to use!
-Postgres is a _fantastic_ "_general purpose_"
-store that has a _rich_ ("_structured_") query language
+`Postgres` is a _fantastic_ "_general purpose_"
+db that has a _rich_ ("_structured_") query language
that lets you JOIN data!!
-Also, now that [`Citus DB` is Open Source](https://www.citusdata.com/blog/2016/03/24/citus-unforks-goes-open-source)
-we _know_ that `Postgres`
-can _easily_ handle ***billions*** of writes per day!
+Also, now that `Citus DB` is fully Open Source
+we _know_ that `Postgres`
+can _easily_ handle **_billions_** of writes per day.
+See:
+[citusdata.com](https://www.citusdata.com/overview/)
## Radical Simplicity
> β_If it takes an hour to figure out whatβs going on, well,
-> thatβs an hour that wasnβt spent
+> thatβs an hour that wasnβt spent
> doing something else more useful and interesting_."
-> ~
+> ~
> [Rachel Kroll](https://rachelbythebay.com/w/2021/09/05/clever/)
Please read:
https://www.radicalsimpli.city
In the site/manifesto
[Stephan](https://www.linkedin.com/in/stephanjschmidt/)
-makes the case that Apps in 2021
+makes the case that Apps
have gotten far too complex:
+> **Note**: the "**Complexity 2021**"
+> is just the year when complex Single Page Apps (SPAs)
+> reached the fever pitch
+> Many people were using the `React`
+> [**hammer**](https://en.wikipedia.org/wiki/Law_of_the_instrument#Computer_programming)
+> to build slow-loading apps with complex architectures.
+> Thankfully, many people/teams
+> have realized that it's a poor UX
+> and moved away from it now.
+
He advocates for a return to basics:
@@ -781,12 +1012,12 @@ No need for microservices message queues or other
complex tech that is only relevant to 0.1% of mega scale companies:
-We agree.
+We agree.
If by some luck our product reaches the point where
-we _need_ mega scale
+we _need_ mega scale
(_millions of `people` creating billions of `items`_)
we know that our chosen stack will scale just fine.
@@ -795,26 +1026,27 @@ and reduce the chances of success.
## Other Tech/Tools?
-We have written about
-our choice of programming language _extensively_ in:
-[learn-elixir/issues/102](https://github.com/dwyl/learn-elixir/issues/102).
+We have written _extensively_ about
+our choice of programming language in:
+[learn-elixir#102](https://github.com/dwyl/learn-elixir/issues/102).
+
+Our use of **`Elixir`** is for a **_very_ specific reason**:
+we are building **fault-tolerant realtime systems**.
+For the type of App we are building,
+**`Erlang/OTP`** is the **_undisputed_ king**
+on the **server side**.
-Our use of **`Elixir`** is for a very specific reason:
-we are building fault-tolerant realtime systems.
-For the type of App we are building,
-`Erlang/OTP` is the _undisputed_ king
-on the server side.
We _could_ use almost any other language/framework,
but it would be a _lot_ more work for an inferior result.
-If we need to build a **_specific_ feature**
-requested by a person _using_ our product,
-then we will **100%** consider a technology
+If we need to build a **_specific_ feature**
+requested by a person _using_ our product/service,
+then we will **100%** consider a technology
that enables us to deliver it.
## How to Propose `NEW` Tech/Tools?
-The way to _propose_ a specific tech/tool
+The way to _propose_ a **specific tech/tool**
is simple:
[open an issue](https://github.com/dwyl/technology-stack/issues)
describe how the tech/tool
@@ -823,15 +1055,31 @@ that has been requested by a person using our product.
_Proactively_ create a **`new` repo**
in the dwyl org
-to capture your own learning
+to capture your own learning
of the tech/tool you are proposing.
-e.g:
+e.g:
[dwyl?q=learn](https://github.com/dwyl?q=learn&type=all&language=&sort=)
-Once you have invested the time
+Once you have invested the time
to learn the tech/tool beyond **`"hello world"`**
and are confident that it will help us
achieve a specific end-goal,
-then _please_ make the case for it.
+then _please_ make the case for it.
+
+# Recommended Reading
+
+This thread on **Hacker News**
+(with 723 comments)
+converges on the "**PETAL**" stack:
+"Ask HN: **What** would be your **stack** if you are **building an MVP** today?"
+https://news.ycombinator.com/item?id=34530052
+It's from 2023 but is still 100% relevant.
+If anything the JS ecosystem is even _more_ fragmented
+and the non-Elixir frameworks haven't caught-up to Phoenix
+which just keeps getting better with each new release.
+
+For a good primer on **Faults, Scaling, and Erlang Concurrency**
+watch Joe Armstrong's Stanford Seminar:
+[youtu.be/YaUPdgtUYko](https://youtu.be/YaUPdgtUYko)
- [](https://hits.dwyl.com/dwyl/technology-stack)
+[](https://hits.dwyl.com/dwyl/technology-stack)
\ No newline at end of file
diff --git a/flutter.md b/flutter.md
index a78af55..fd1d337 100644
--- a/flutter.md
+++ b/flutter.md
@@ -2,17 +2,19 @@
# `Flutter`
-**Creative technology**
+**Creative technology**
is **_constantly_ evolving**.
There is always
-a **`new` way**
-of ***solving*** an
+a **`new` way**
+of **_solving_** an
**old problem**
-and in some cases
-**_significantly_ simplifying**
+and in some cases
+**_significantly_ simplifying**
the solution.
+
@@ -25,7 +27,6 @@ after all there are still plenty of jobs writing [FORTRAN](
This works in the _short-term_ because
most _organisations_ take a long time to adopt new tech
so people can cling onto their ageing knowledge.
-
-->
# _Why_? π€·ββοΈ
@@ -34,17 +35,17 @@ so people can cling onto their ageing knowledge.
If I was **starting** my journey **from _scratch_** now
**what tech** would I learn/use?
-If we could keep all
+If we could keep all
the knowledge/wisdom and experience gained
-over 20+ years of programming
-but avoid any preconceptions and biases
-i.e.
-["sunk cost bias"](https://en.wikipedia.org/wiki/Sunk_cost#Fallacy_effect).
-Would we still choose the tech/tools we are _currently_ using?
-Or would we pick something else completely different?
-
-
-The people/teams/organisations that can _objectively_
+over 20+ years building Apps,
+but avoid any preconceptions and biases
+(e.g:
+[**sunk cost bias**](https://en.wikipedia.org/wiki/Sunk_cost#Fallacy_effect)
+).
+Would we **still choose** the **tech/tools** we are **_currently_ using**?
+Or would we pick something else **completely different**?
+
+The people/teams/organizations that can _objectively_
question why they use particular tech/tools
can take advantage
of all the advancements being made
@@ -56,35 +57,45 @@ The question we need to ask/answer
_before_ diving into any discussion
of which technology/language/framework
we should or shouldn't use is:
-**What are _problem_ are we _trying_ to _solve_?**
+## What _Problem_ Are _Solving_?
+
+We are trying to deploy a **`Native` Mobile App**
+that **launches fast** and **performs well** (with a low memory footprint)
+on both `Android` and `IOs`.
+
+`Flutter` solves this for us
+and allows maximum cross-platform code-reuse.
-The last time we (_informally_) looked at `Flutter` in early 2018,
-it did _not_ meet all our needs for a UI framework.
-At the time, it was focussed on Android,
+When we (_initially_) looked at `Flutter` in early 2018,
+it did _not_ meet all our needs for a UI framework.
+At the time, it was focussed on `Android`,
didn't support Web/PWAs
-and only had partial/beta support for IOs.
+and only had partial/beta support for `IOs`.
In the last couple of years `Flutter` has seen _rapid_
development both from the _army_ of **Google** Developers
and the thriving community and it has matured considerably.
It _excels_ at _all_ of our requirements.
+# Who?
+
Google is using `Flutter`
for several of their cross-platform Native Mobile Apps
including **Google Adds** (_their main money maker_)
and **Google _Pay_** their popular global payments platform.
-See:
+See:
[flutter.dev/showcase](https://flutter.dev/showcase)
[](https://flutter.dev/showcase)
-There are _thousands_ more examples and more each day!
+There are _hundreds of thousands_ more examples
+and hundreds more published each day!
-It's almost certain that you are _already_ using an App on your Smart Phone
-that was built with `Flutter` whether you know it or not.
+It's almost certain that you are _already_ using an App on your Smart Phone
+that was built with `Flutter` whether you know it or not.
For a community list of Apps built with `Flutter`
including many Open Source ones, see:
@@ -198,65 +209,80 @@ All the _practical_ detail is there.
# Background
-We are building our App:
+We are building our `App`:
[dwyl/app](https://github.com/dwyl/app).
-We selected **`Phoenix`** for the Backend
-because we find **`Elixir`** easy to read, reason about and write.
-(far more so than other major programming languages).
-More detail in:
-[learn-elixir/issues/102](https://github.com/dwyl/learn-elixir/issues/102)
-The data we are storing is _relational_ in nature.
-We are creating `items` of `text`
-that have an _unlimited_ length.
-We want to apply meta data to those `items`
-and create rich interactions around them.
-We will have _many_ useful features in the App
-but the core will be `items`, `timers`, `lists` and `people`.
-
-As a _small_ team with finite resources
-(_and no desire to "raise" money from outside investors_),
-we want to maximise our efforts
-to build the App that _most_ people want/need.
-We are focussing on building the Web App initially
-because the web is universally accessible.
-_Many_ companies have focussed their initial efforts on `iOS`
-because it's the _easiest_ platform to target,
-`iOS` users have more disposable income
+We selected **`Phoenix`** for the Backend
+because we find **`Elixir`** easy to read, write
+and reason about.
+(far more so than other major programming languages).
+More detail in:
+[**learn-elixir**](https://github.com/dwyl/learn-elixir/#key-advantages-)
+The data we are storing is _relational_ by nature.
+We are creating `items` of `text`
+that have an _unlimited_ length.
+We want to apply `metadata` to those `items`
+and create rich interactions around them.
+We will have _many_ useful features in the `App`
+but the core will be:
+`items`, `timers`, `lists`, `people` and `groups`.
+
+As a _small_ team with finite resources
+
+we want to maximize our efforts
+to build the `App` that _most_ people want/need.
+We are focussing on building the **`Web App`** initially
+because the web is universally accessible.
+_Many_ companies have focussed their initial efforts on `iOS`
+because it's the _easiest_ platform to target,
+`iOS` buyers have more disposable income
and are more likely to _pay_ for apps.
> "_Making an App for `iOS` is Faster and Less Expensive_".
-> "_`Android` users tend to be
-> less willing to pay for apps than `iOS` users,
-> so free apps with in-app ads are more common._"
+> "_`Android` users tend to be
+> less willing to pay for apps than `iOS` users,
+> so **free apps** with **in-app ads** are more common._"
https://medium.com/@the_manifest/android-vs-ios-which-platform-to-build-your-app-for-first-22ea8996abe1
-> There are fewer iOS devices to target and test on which dramatically shortens dev timelines.
-e.g in 2022 there are only **7 supported screen sizes** for iPhone:
-> + 4" - iPhone 5S and SE (old screen size but still used by [tens of millions](https://deviceatlas.com/blog/most-popular-iphones) people)
-> + 4.7" - iPhone 6, 7, 8 and SE 2020 & 2022
-> + 5.42" - iPhone 12 & 13 Mini
-> + 5.5" iPhone 6 Plus, 7 Plus and 8 Plus
-> + 5.85" - iPhone X, XS and 11 Pro
-> + 6.06" - iPhone XR, iPhone 11, 12 & 13 Pro
-> + 6.46" - iPhone XS Max and iPhone 11, 12, 13 Pro Max
-See: https://en.wikipedia.org/wiki/List_of_iOS_devices
-The _full_ device feature compatibility matrix
-is lets developers see _exactly_ what features are available for all iOS devices (including all iPads): https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
-
-> In **2015** there were _already_
-> "_more than **24,000 different `Android` devices**
-> from 1300 brands_"
+> There are fewer iOS devices to target
+> and test on which dramatically shortens dev timelines.
+e.g in 2026 there are only **8 supported screen sizes** for iPhone:
+
+> + 4.7": iPhone SE (2nd & 3rd generation)
+> + 5.42": iPhone 12 & 13 Mini
+> + 5.5": iPhone 6 Plus, 7 Plus and 8 Plus
+> + 5.85": iPhone X, XS and 11 Pro
+> + 6.06": iPhone 11, 12, 13 Pro, 14 Pro
+> + 6.3": iPhone 15 Pro, 16 Pro, 17
+> + 6.46" iPhone 11, 12, 13 & 14 Pro Max
+> + 6.7": iPhone 16 Plus
+> + 6.9": iPhone 16 Pro Max, iPhone 17 Pro Max
+See:
+[support.apple.com/en-gb/guide/iphone/iphe3fa5df43/ios](https://support.apple.com/en-gb/guide/iphone/iphe3fa5df43/ios)
+and
+[wikipedia.org/wiki/List_of_iOS_devices](https://en.wikipedia.org/wiki/List_of_iOS_devices)
+The _full_ device feature compatibility matrix
+lets developers see _exactly_ what features
+are available for all iOS devices (including all iPads):
+https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
+
+## How Many Distinct `Android` Devices
+
+By **2015** there were _already_
+"_more than **24,000 different `Android` devices**
+from **1300 brands**_"
https://www.zdnet.com/article/android-fragmentation-there-are-now-24000-devices-from-1300-brands
+
+
That was before the _explosion_ of new devices from Chinese and manufacturers.
-In 2022 there is no official stat
-for the number of devices or screen sizes
-(_because Google is painfully aware
-of the fragmentation problem
-but doesn't want to surface it!_)
-suffice to say that it's _several_ orders of magnitude
-more complex to build an Android App
+In 2026 there is no official stat
+for the number of devices or screen sizes
+(_because Google is painfully aware
+of the fragmentation problem
+but doesn't want to surface it!_)
+suffice to say that it's **_several_ orders of magnitude**
+**more complex** to **build** an **`Android App`**
that looks _consistently_ good across all devices.
-Android development is _considerably_ more complex,
+Android development is _considerably_ more complex,
which is why devs prefer `iOS` for their MVP.
@@ -277,9 +303,13 @@ and was the 3rd "most loved" framework:
[https://insights.stackoverflow.com/survey/2020#technology-most-loved](https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools-loved3)
-In the 2022 survey `Flutter`
-has overtaken `React Native`
-in popularity:
+In the 2022 survey `Flutter`
+overtook `React Native`
+in popularity:
https://survey.stackoverflow.co/2022/#section-most-popular-technologies-other-frameworks-and-libraries
+and in all years since it has maintained its' lead:
+https://survey.stackoverflow.co/2025
+
[](https://hits.dwyl.com/dwyl/technology-stack)
+
diff --git a/legacy/README.md b/legacy/README.md
index 851e6d8..2b87515 100644
--- a/legacy/README.md
+++ b/legacy/README.md
@@ -5,19 +5,22 @@ We have deployed our **`Node.js`** stack for _many_ clients
and internal apps and achieved good results!
It works well and we have not had any issues with "_performance_"
or "_scaling_" deploying to AWS.
-> For an example of app built using our Node.js Stack
-see: https://github.com/TheScienceMuseum/collectionsonline
+
+> For an example of app built using our Node.js Stack,
+see: [TheScienceMuseum/collectionsonline](https://github.com/TheScienceMuseum/collectionsonline)
+Still runs smoothly and has been maintained and extended over 10 years!
+[collection.sciencemuseumgroup.org.uk](https://collection.sciencemuseumgroup.org.uk)
There's no "_reason_" to "_rewrite_"
any of our _existing_ projects to _any_ other "_stack_".
-**`Node.js`** works perfectly well
-and will continue to be supported
-for the lifetime
-of the project(s)
+**`Node.js`** works perfectly well
+and will continue to be supported
+for the lifetime
+of the project(s).
-> See: "***tl;dr***" section below if you are _interested_
-in ***why*** we decided to "_evolve_"
-to "***PETAL***" for ***new*** projects...
+> See: "**TL;DR**" section below if you are _interested_
+in **_why_** we decided to "_evolve_"
+to "**_PETAL_**" for **_new_** projects...
## Overview
@@ -25,16 +28,19 @@ The following diagram is an overview of our **`Node.js`** stack:
-> Note: To edit/improve this diagram: https://github.com/dwyl/technology-stack/issues/1
+> Note: To edit/improve this diagram:
+> [dwyl/technology-stack#1](https://github.com/dwyl/technology-stack/issues/1)
-We have produced a ***complete beginners guide***
-for *each* of the components in our stack. (see below)
+We have produced a **_complete beginners guide_**
+for _each_ of the components in our stack. (see below)
## Open Source Projects We Use
-### For Us *By* Us
+### For Us _By_ Us
-We ***craft code*** to [***scratch our own itch***](https://github.com/dwyl/start-here#our-approach-scratching-your-own-itch) and ***everything*** we do is ***always Open Source***
+We **_craft code_** to
+[**_scratch our own itch_**](https://github.com/dwyl/start-here#our-approach-scratching-your-own-itch)
+and **_everything_** we do is **_always Open Source_**.
| Project | Used For | Build Status | Test Coverage | Dependency Status | Tutorial |
| --------|----------|:-----:|:--------:|:------------:|-------|
@@ -62,21 +68,21 @@ https://github.com/dwyl/learn-hapi
It enables realtime, bi-directional communication between web clients and
server. Socket.io lets us send data to/from everyone connected to our app(s)
without having to refresh the web page. https://socket.io/
-+ **Riot.js** - is the most ***light-weight*** user-interface (UI) framework
++ **Riot.js** - is the most **_light-weight_** user-interface (UI) framework
available which is compatible with IE 8/9 and has good
-server-side rendering (*which means pages load faster for slow devices like budget smart phones*).
+server-side rendering
+(_which means pages load faster for slow devices like budget smart phones_).
see: https://github.com/dwyl/learn-riot
-+ **Redis** - the most popular *in-memory* data store which is *essential*
-for building the ***fastest possible*** apps.
++ **Redis** - the most popular _in-memory_ data store which is _essential_
+for building the **_fastest possible_** apps.
read more: https://github.com/dwyl/learn-redis
+ **ElasticSearch** - the most feature-rich search engine. we use
it to find things fast. Learn more: https://github.com/dwyl/learn-elasticsearch
-
### Development Dependencies
-We *carefully* select and only use *well-maintained*
-"*pure*" JavaScript modules
+We _carefully_ select and only use _well-maintained_
+"_pure_" JavaScript modules
in our development toolchain:
+ **Tape** for testing: https://github.com/dwyl/learn-tape
@@ -90,5 +96,4 @@ https://github.com/dwyl/learn-istanbul#tracking-coverage-as-a-service
+ **CodeClimate** for tracking code quality:
https://github.com/dwyl/learn-codeclimate
-
- [](https://hits.dwyl.com/dwyl/technology-stack)
+[](https://hits.dwyl.com/dwyl/technology-stack)
diff --git a/legacy/package.json b/legacy/package.json
index a4193fc..7187f80 100644
--- a/legacy/package.json
+++ b/legacy/package.json
@@ -1,6 +1,6 @@
{
"name": "technology-stack",
- "version": "1.0.2",
+ "version": "2.0.1",
"description": "Clarity for all Technology used in DWYL products & client work.",
"repository": {
"type": "git",
@@ -9,58 +9,6 @@
"author": "dwyl & co",
"license": "GPL-2.0",
"homepage": "https://github.com/dwyl/technology-stack#readme",
- "dependencies": {
- "env2": "^2.1.1",
- "esta": "^4.2.0",
- "goodparts": "^1.0.4",
- "hapi-auth-jwt2": "^7.1.3",
- "hapi-error": "^1.1.3",
- "hapi-login": "^1.2.2",
- "hapi-postgres-connection": "^6.1.0",
- "hapi-redis-connection": "^5.0.0",
- "hapi-register": "^1.1.0",
- "hapi-riot": "^1.0.2"
- },
- "learn": {
- "env2": {
- "use": "Loading Environment Variables",
- "repo": "learn-environment-variables"
- },
- "hapi-auth-jwt2": {
- "use": "Authentication & Sessions",
- "repo": "learn-json-web-tokens"
- },
- "hapi-redis-connection": {
- "use": "Simplify Redis Connection",
- "repo": "learn-redis"
- },
- "esta": {
- "use": "ElasticSearch CRUD",
- "repo": "learn-elasticsearch"
- },
- "hapi-postgres-connection": {
- "use": "Postgres Connection Pooling",
- "repo": "learn-postgresql"
- },
- "hapi-riot": {
- "use": "Server-side (Fast) Rendering of Riot Tags",
- "repo": "learn-riot"
- },
- "hapi-error": {
- "use": "Human-Friendly Error Messages",
- "repo": "hapi-error#why"
- },
- "goodparts": {
- "use": "Consistent Code (Linting & Style)",
- "repo": "goodparts#why"
- },
- "hapi-login": {
- "use": "User Login",
- "repo": "learn-hapi"
- },
- "hapi-register": {
- "use": "User Registration",
- "repo": "learn-hapi"
- }
- }
+ "dependencies": {},
+ "learn": {}
}
\ No newline at end of file