Open nelsonic opened 2 years ago
@SimonLab please have a read through this and LMK if it makes sense. Thanks. π
Going to add an ERD
to the auth
App as it's sorely lacking.
Ref: https://github.com/dwyl/learn-postgresql/issues/84
There have been some recent developments in phx mix.gen.auth
... https://youtu.be/9-rqBLjr5Eo #222
Looking like this will happen pretty soon: https://github.com/dwyl/learn-phoenix-framework/issues/152 π€
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 ... π
Side-quest: https://github.com/dwyl/auth/issues/284
In light of the maturity of
mix phx.gen.auth
π (that didn't exist #133 when we originally started buildingAuth
...), I propose that we re-buildauth
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 https://github.com/dwyl/auth/issues/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 adds2kloc
to the codebase and has nowhere near the level of features, docs or tests this project has. We didn't want to useauth
for the Client project because it's not "polished" enough. Theauth
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 inauth
"v1" and we want for "v2.0".Our objective is to have a seamless Auth UX for people running the
App
on theirlocalhost
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.[ ] Use
Tailwind
https://github.com/dwyl/technology-stack/issues/94 for UI as it'll be inPhoenix v1.7
β¨App
![ ] Use
LiveView
where appropriate https://github.com/dwyl/phoenix-liveview-counter-tutorial/issues/74 e.g. "Who is Online" viaPresence
[ ] Use
Swoosh
(which also didn't exist when we createdAuth
originally)[ ] Keep
auth.dwyl.com
as a independent/separate deployed App so that we can keep the "core" of theApp
so that people running it only have ONE environment variable they can get in less than 1 minute.[ ] Run
auth
on TCP Port4001
onlocalhost
to make easier to run both theApp
on the same machine if the person is busy testing while offline.[ ] Create a comprehensive
Admin
DashboardPHP
is horrible...!)At present we have this basic dashboard of the
people
: https://auth.dwyl.com/peopleBut we could go much further.
e.g: https://auth.dwyl.com/people/3![image](https://user-images.githubusercontent.com/194400/172406796-aeadf707-5b8c-43e2-bdc3-71b3e51a436e.png)
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
Elixir
,Phoenix
and other language apps!! Initial success would be anyone else inPhoenix-land
using ourAuth
implementation, long-term success would be people inPython
,Node.js
or evenRails
using it! But in the first instance, we just want to make it easier for ourselves to maintain and others to contribute.App
setup e.g. pasteURL
of a logo.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:mix phx.new
andmix phx.gen.auth
with aNext 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.