Stronger
Sophisticated strength and conditioning log
Finished wiring up the initial local database (#sqlite) and remote database (#postgresql) sync over the weekend. Main necessity for this was to make sure new a user's IDs will match between local db an remote db.
This initial/minimal sync is the only one that will be done for users that don't opt to use the cloud sync feature. It ensures that if at any point they do opt into it, all the rows in their local tables will relate to the same user ID that the remote db has on record.
With that set up, any sync upon future opt-in will be as straightforward as running through all the local table rows and saving them to the remote database.
I'm definitely "putting the cart before the horse" a bit by figuring all this out before I have any core features (i.e. exercise/workout logs) built. But I guess that's a benefit of solo/side-projects — I can go down whatever rabbit holes I want to, whenever I choose to. 😊
Yesterday and later today I'm working on wiring up an SQLite service to use throughout the app. Figuring out how to do that with the expo-sqlite and expo-filesystem libraries. Haven't used either before.
All features should be completely capable offline, giving users the option to sync their data to the remote database. The remote sync could be convenient when switching between devices, but also for features that will automate export/sync to third-party apps (e.g. Notion).
This is the first app I've worked on where I need to orchestrate reliable (and sporadic) syncing between device databases and a remote database to handle potential conflicts.
More on that later. Staying focused on the essential features for now.
Completed essential sign-up/sign-in UI flows and auth architecture for Stronger, with some less immediately necessary parts still to finish. This is a "boring but necessary" part of new app development, but I do think I put too much initial time/attention into it...
Why bother putting a bunch of time into refining auth features, if I don't yet have any features built-out for users (including myself) to even begin using? So, upon reflection, I kinda "nerd-sniped" myself into spending too much up-front time refining these initial auth flows.
In one of @fireship_dev's recent videos, he reflected on keeping to anonymous auth flows to minimize sign-up friction for users. I may switch to that and the "magic link" strategy for sign-in, when I'm closer to having a usable product. 🤔
One reason so much tinkering ensued is because I'm using Firebase Auth in React Native for the first time. So it turned into a lot of exploring and experimenting with the APIs.
There were some gotchas using the Firebase password reset strategies. I was late to realize the UI flows I had designed and coded required additional deep linking setup. For now, I reverted some of that work to use Firebase's default browser flow.
I know Firebase services can become expensive at scale, but I've been enjoying the mobile development experience — in particular, being able to run a local Firebase emulator during development is very nice.
-
1
I agree auth service is necessary and boring 🥲 in the end i just provide google auth for users to sign up , it’s one button and frictionless for users, the good news is once had it figured out , the code can be reused in many projects, that's how I motivate myself to code it 😂
-
1
I did consider going with a third-party OAuth provider, like Google. But then it's a matter of having to set up multiple (e.g. Google, Apple, Twitter) because I wouldn't want to limit users to one choice. Setting that up is fairly simple with Firebase Authentication, but I just decided to keep it basic with email/password, for now. It was also a good practice opportunity for me because it had been a while since I built out an auth flow.
I'll add third-party OAuth options later. And, like you mention, I now have a well-organized auth flow that I can easily reuse in other projects.
-
-
1
We use Auth0 for our Sign-in and Sign-up flows and it is very easy to use and integrate
-
1
Nice. I've used Auth0 on past projects. Using Firebase Auth feels pretty comparable. I went with Firebase because it has other APIs I'm interested to use within my app. It's also integrated with Google Cloud Platform, which I'm using to host my server and database.
-
1
That makes sense. All the best with your app :)
-
-
First and foremost, this project will be me giving #buildinginpublic and #learninginpublic a genuine try. For years I've watched a handful of indie hackers do so. The public accountability and consistent feedback seems to really give them extra momentum for shipping features and experimenting with new ideas.
I also envy those developers for being able to look back at a detailed record of their learnings and projects, often over years of posts. I've tried many times to do the same in a private journal, but consistency has been challenging without the pressure of a potential audience.
I've thought about working on side projects in public many times, and have had a couple false starts. I always procrastinated the idea into the ground or simply psyched myself out — I generally don't enjoy attention from strangers. But here goes... 🫣
Currently, my main personal project is a "scratch my own itch" app for tracking my strength and conditioning programs, sessions and metrics. So I'm starting there.
I've tried SO MANY other fitness tracking apps, but I'm always unsatisfied with the features. I always return to using a collection of Notion databases and templates that have become my prototype for this project.
My desired features are very particular and opinionated, so I'm not sure how many others would have use for most of them. But I'm building the app with that possibility in mind.
So here's kicking off my first #buildinpublic and #learninpublic experiment. 😬 Regardless of how this project goes, I know I'll learn a lot and build an app I personally want to use. And maybe sharing the process will lead to steadier progress and making some new friends along the way. 🙂
Comment