Bringing Meraki Online - 2. Auth Is Hard

In its current state Meraki has no notion of users and stores everything locally. Therefore, the first step in supporting cloud persistence of tasks is to create the concept of users such that data can be associated with them and that account can be accessed from various platforms.

Lucky enough Supabase provides Authentication, however diving into the space I quickly discovered Auth is hard.

To be clear Supabase makes most of this quite easy up front, however there’s so many edge cases to consider which I didn’t realize until diving into it all. For this app, I wanted to support a few options; Sign in with Apple, Google, Email, and an anonymous guest user to allow people to continue using the app on a single device without needing to sync across platforms.

To get started with everything I created an AuthManager to handle the different sources and interact with Supabase and threw together a simple UI with the providers and an email input field. I’ll be honest, a decent amount of time was spent on throwing together the UI. Its the first thing new users see, it can’t be ugly and has to fit with the overall aesthetic of the application.

Apple, Google, and Anonymous are all fairly straight forward and took about a day to setup all of them. Email took me the rest of the week. Here I was thinking I’ll spend a weekend on auth and then move onto the data schema and actual product development. Not only does email have a more involved UI to create, I realized I have to handle input validation, sign ups for new users which was a whole other UI flow, and forgotten passwords. These are all features which Supabase does support at a high level, but there’s additional details such as needing to bring up an email server for password recovery and handling abuse of account creation that need to be considered. Part of me wanted to avoid the whole reset password option which I could do through the use of OTP. For that I would still need an email server and so I switched to focus on that.

Originally I found a github comment that stated I could leverage my free gmail account as the SMTP server, but I was unsuccessful, probably because I do need a paid Google Workspace account to use this. Eventually I opted to use resend which was quite easy to setup and use and I’m a fan of so far.

At this point I’m able to get emails from Supabase to my user working, but I haven’t built out a password recovery flow. I figure the password recovery flow would be online and part of the web app, so it would be worth building that later, rather than setup a web app and handle serving that to users. Sorry if you forget your password in the short term. Instead I can now get a user to sign up, login with that email, send the email to recover a password, or also use any of the other auth providers. This was good enough to get users populating in the backend and get moving on the actual application logic.

During this experience I started to see the value in services like Auth0 and Clerk. I started going down a rabbithole because I realized Anonymous user’s can be abused to create users without limits and bloat my database, or spamming my password recovery could cause me to hit my resend quota and increase expenses. These services help with these issues and so would be valuable to work with eventually. Another issue I discoverd was stale Anonymous users. What happens when an Anonymous user deletes the app. We need a way to reap their data if it becomes stale. That’s something to handle in the future and I’ll come back to. But for now we have users.