In light of the maturity of mix phx.gen.auth 🎉
(that didn't exist #133 when we originally started building Auth...),
I propose that we re-build auth from first principals 0️⃣
but with a similar goal & feature-set: 🎯 🔐
to enable 1-EnVar Setup^TM of the ("core") App. 🚀

Why? 🤷‍♂️

Why would we do this when our auth app already works: https://auth.dwyl.com ??

Firstly, as noted by @SimonLab in #153 the application workflow is unclear. 😕
If Simon finds it convoluted, then heaven help someone else who is unfamiliar with it. 🤦‍♂️

I find the code reasonably readable because I wrote much of it.
But that's meaningless if the second highest contributor finds it unwieldy.
We need it to be immediately obvious to a complete beginner what's going on.

Why We Built our Own [Custom] Auth Experience in First Place ...? 💭

As we've recently seen on a recent Client project,
building auth directly into the "main" Phoenix App adds 2kloc to the codebase
and has nowhere near the level of features, docs or tests this project has.
We didn't want to use auth for the Client project because it's not "polished" enough.
The auth that we've built for the Client project is suuupper slimmed down; it only has email+password and basic verification. No OAuth - e.g. Google Auth which we determined was a no-brainer for startups and small B2B apps - mix phx.gen.auth has only basic Session Management, No support for being logged in on Multiple Devices, No Roles, Permissions or Dashboards.
Those are the "batteries included" we already have in auth "v1" and we want for "v2.0".

Our objective is to have a seamless Auth UX for people
running the App on their localhost so that we can streamline contribution.

What? 📝

• Create an /auth folder in https://github.com/dwyl/book with various .md files e.g. README.md, part1.md, part2.md etc. to capture the journey.

  • This way we can split out the creation of the app into various 20-min chunks that people read in their own time. The clear advantage: maintainability!

• Use Tailwind Tailwind CSS technology-stack#94 for UI as it'll be in Phoenix v1.7 ✨

  • Specifically make it Mobile First as it's what we will need for our App!

• Use LiveView where appropriate Optimizing User Experience with LiveView phoenix-liveview-counter-tutorial#74 e.g. "Who is Online" via Presence

• Use Swoosh (which also didn't exist when we created Auth originally)

• Keep auth.dwyl.com as a independent/separate deployed App
  so that we can keep the "core" of the App so that people running it
  only have ONE environment variable they can get in less than 1 minute.

• Run auth on TCP Port 4001 on localhost to make easier to run both the App on the same machine if the person is busy testing while offline.

• Create a comprehensive Admin Dashboard

  • For ref: https://retool.com/blog/best-laravel-admin-panels/ (but PHP is horrible...!)

At present we have this basic dashboard of the people: https://auth.dwyl.com/people

Note: just spotted a bug: Last Login is not displayed correctly.

But we could go much further.

e.g: https://auth.dwyl.com/people/3

You can immediately tell from the UI that it's inconsistent and built by someone who is very clearly not a "designer" ... We can do muuuuch better!!

Potential Enhancements

• "White-label" it to make it easier for others to re-use it in their Elixir, Phoenix and other language apps!! Initial success would be anyone else in Phoenix-land using our Auth implementation, long-term success would be people in Python, Node.js or even Rails using it!
  But in the first instance, we just want to make it easier for ourselves to maintain
  and others to contribute.
• Allow inclusion of the Logo via code or App setup e.g. paste URL of a logo.
• Automatically verify people who register using an email and password if the redirect URL is localhost to speed-up development.

How? 👩‍💻

I propose that in addition to writing a step-by-step tutorial, similar to /dwyl/phoenix-chat-example etc ...
We use this as an opportunity to create a tutorial mini series of videos that we upload to YouTube!

Where to Start? > Entity Relationship Diagram (ERD)!

Start by creating a Entity Relationship Diagram (ERD) that maps out all the features we've already built in v1.

The page of the /tutorial and first video should be just:

• dev environment setup,
• mix phx.new and
• mix phx.gen.auth with a
• walkthrough of all the code that is created.

Next we can go through the ERD and breakdown the required features.

Will need to return to this later.
But wanted to open the issue to reference it.