Phoenix 1.6 is organizing around WebSockets with Phoenix LiveView and presents a paradigm shift in web frameworks.

Phoenix 1.6 Release Candidate is out and I am currently in the process of assessing a migration to that version from the legacy codebase started on Phoenix 1.3 running Folkbot.com today.

The current folkbot.com codebase has been an ongoing hobby project since Phoenix 1.3. and contains many experiments and implementation patterns. Implementations derived from the first Phoenix book, alchemist.camp, elixircasts, changelog.com and so on. Some of the original implementations came from blog posts before the official book which established unofficial community-style guidelines.

Phoenix 1.6 is reorganizing around WebSockets and is less about HTTP and REST (although these obviously are massive pillars of the ecosystem). WebSockets present a paradigm shift in the internet and web. Phoenix LiveView brings WSS into the center and Phoenix LiveView is maturing as the keystone of the Elixir Phoenix ecosystem.

It is extremely difficult to overstate the importance of WebSockets manifested in Phoenix LiveView.

On Folkbot.com the technical debt has gotten to a position where I am seriously considering terminating the development of the current codebase and cherry-picking custom code and implementations and moving them over to a clean and minimal implementation using Phoenix 1.6.

This is my current plan

Design

Folkbot.com 2

• [ ] Bring what works from Folkbot.com 1 to Folkbot 2

• [x] Use Phoenix 1.6
• [ ] Use PETAL: Phoenix, Elixir, Tailwind, Alpine, Liveview
• [ ] Do small experiments using the Experiment.Folkbot.dev subdomains and push to Github and publish on a blog (ideally Folkbot?)
• [ ] Use Tests and keep them updated
• [ ] Experiments are on branches and will be deployed rapidly to Github and fly.io
• [ ] Update deployments to deploy only binaries
• [ ] Use subdomains for sites, not umbrella apps
• [ ] Use components
• [ ] Use changelog style authorization policies or Bodyguard
• [ ] Do NOT use Entity system, focus on simplicity
• [ ] Avoid complex nested join tables
• [ ] Build JSON, Graphql, Liveview and HTML for each content type
• [ ] Make Users and their channels key
• [x] Use SnowflakeId https://www.folkbot.com/posts/25-snowflake-id-for-users
• [ ] Focus on conventions and not complexity
• [ ] Mobile first UX design
• [ ] Use Lean Product framework
• [ ] Use Phoenix LiveView for authenticated sessioned content
• [ ] Use Phoenix HTML for static cached CDN content, suitable for Varnish or Nginx or cloud CDN.
• [ ] Either fork or contribute back to various packages that are used
• [ ] Use Browserstack for mobile first design
• [ ] Gtmetrix and web.dev very high scores
• [ ] Get away from Umbrella projects
• [ ] Keep the project extremely lean
• [ ] Experiment with custom generators that allow for recreation of all content types using similar patterns

Image Credit: https://elements.envato.com/phoenix-mascot-vector-illustration-MSE8NEZ

Accounts and Users https://www.folkbot.com/posts/24-phoenix-1-6-accounts-users

Snowflake ID for Users https://www.folkbot.com/posts/25-snowflake-id-for-users

Posts | Channels