Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Rebuild Auth App using mix phx.gen.auth when Phoenix@1.7 Ships #207

Open
17 tasks
nelsonic opened this issue Jun 7, 2022 · 11 comments
Open
17 tasks
Assignees
Labels
chore a tedious but necessary task often paying technical debt discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. help wanted If you can help make progress with this issue, please comment! needs-ui A feature idea that needs UI in order to be discussed/built. priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished research Research required; be specific tech-debt A feature/requirement implemented in a sub-optimal way & must be re-written technical A technical issue that requires understanding of the code, infrastructure or dependencies

Comments

@nelsonic
Copy link
Member

nelsonic commented Jun 7, 2022

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 SetupTM 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

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

image

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
image

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.

@nelsonic nelsonic added enhancement New feature or enhancement of existing functionality priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished chore a tedious but necessary task often paying technical debt discuss Share your constructive thoughts on how to make progress with this issue technical A technical issue that requires understanding of the code, infrastructure or dependencies labels Jun 7, 2022
@nelsonic nelsonic self-assigned this Jun 7, 2022
@nelsonic nelsonic pinned this issue Jun 7, 2022
@nelsonic nelsonic added help wanted If you can help make progress with this issue, please comment! epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. needs-ui A feature idea that needs UI in order to be discussed/built. research Research required; be specific tech-debt A feature/requirement implemented in a sub-optimal way & must be re-written labels Jun 7, 2022
@nelsonic
Copy link
Member Author

@SimonLab please have a read through this and LMK if it makes sense. Thanks. 👍

@nelsonic
Copy link
Member Author

Going to add an ERD to the auth App as it's sorely lacking.
Ref: dwyl/learn-postgresql#84
image

@nelsonic
Copy link
Member Author

There have been some recent developments in phx mix.gen.auth ... https://youtu.be/9-rqBLjr5Eo #222

image

@nelsonic nelsonic changed the title Proposal: Rebuild Auth App using mix phx.gen.auth Proposal: Rebuild Auth App using mix phx.gen.auth when Phoenix@1.7 Ships Oct 14, 2022
@nelsonic
Copy link
Member Author

Looking like this will happen pretty soon: dwyl/learn-phoenix-framework#152 🤞

@nelsonic
Copy link
Member Author

Reading through all the changes - many of them breaking changes - in: https://github.com/dwyl/phoenix-liveview-counter-tutorial/pull/104/files I'm a little put off by continuing to pour my time into Phoenix given the maintenance burden. ⏳ 🙄

If we look back at Healthlocker: https://github.com/healthlocker/healthlocker which was paused in 2018.
The Dev effort to update it from Phoenix @1.2.1 to 1.7 would be similar to re-writing it from scratch.
So much has changed - not always for the better - that it makes me quite sad. 😞
As people who write software to solve a specific problem I favour stability and ease of maintenance over shiny new features every time. Renaming, deprecating or moving things around basically voids the time investment made into building the product because the maintenance cost is too high.

I feel like I'm being forced to adopt features I never signed up to because of Sunk Cost Bias: https://en.wikipedia.org/wiki/Sunk_cost

To be 100% clear: if I was completely new to Elixir and Phoenix I wouldn't feel this way.
I think the work that has been done in the last few years is superb. LiveView is game-changing.
But as someone who has to maintain existing projects, it's such a burden!
I want to be building features not "upgrading" my perfectly working project
and dealing with dependency conflicts and deprecations! 😢

Hmm ... 💭

@nelsonic
Copy link
Member Author

@nelsonic
Copy link
Member Author

nelsonic commented Mar 8, 2023

@nelsonic
Copy link
Member Author

nelsonic commented Mar 8, 2023

Side-quest: #284

@nelsonic
Copy link
Member Author

phx-auth-login-page-confusing

@nelsonic
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore a tedious but necessary task often paying technical debt discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. help wanted If you can help make progress with this issue, please comment! needs-ui A feature idea that needs UI in order to be discussed/built. priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished research Research required; be specific tech-debt A feature/requirement implemented in a sub-optimal way & must be re-written technical A technical issue that requires understanding of the code, infrastructure or dependencies
Projects
Status: Backlog (Prioritized)
Status: No status
Development

No branches or pull requests

2 participants