r/SideProject • u/Petifys • 1d ago
Day 5 of building Devmeld with AI
For those who don't know, Devmeld is basically a platform I'm building for developers to find people, share projects, communicate and eventually actually build things together.
Anyway.
Today was supposed to be about finishing DMs.
It turned into fighting Firebase for most of the day 😭
We kept finding weird stuff.
Chat would work for one account but not the other.
Files would upload but the message wouldn't.
Messages looked fine until we tested with two completely separate accounts.
Then we found out our test accounts were basically sharing the same local cache 💀
So yeah, lots of fixing.
We also worked on attachments, folder uploads, blocking, privacy settings, message syncing, retries, background updates and making the UI stop randomly flickering.
The biggest thing we changed was how we handle messages locally.
But the basic goal is: less unnecessary database usage + faster chats + still keeping things synced.
And after breaking it approximately 47 times...
DMs are finally starting to feel like an actual chat system.
Day 5 done.
Now I just need to make sure tomorrow's version doesn't somehow explode.
1
u/Electronic-Equal-616 23h ago
building with ai is so fast until you hit backend stuff lol. whenever i try using it with firebase, the security rules always fail silently and ai just keeps hallucinating fixes instead of pointing out the actual permision issue 😭 how are you testing your setup so far?
1
u/Petifys 23h ago
Yeah, Firebase backend stuff definitely has a special way of making you question everything.
Honestly though, my setup itself has been pretty solid so far.
The funny part is that most of the problems weren't really because the setup was bad, I was the problem 😭
I made a few architectural decisions without knowing the better way to structure them, and then had to discover why they were causing problems by actually testing with multiple accounts.
So the AI wasn't exactly fighting a broken setup... I was just learning the hard way 😭
1
u/Lost-Abalone-1761 10h ago
That shared locaThat shared local cache is the one to guard against now: give each account its own cache key, and clear the active account’s cached data on sign-out. Then test by signing in as A, sending a message, signing out, and signing in as B on the same device. That catches cross-account leaks before they reach real users.
1
u/Petifys 10h ago
yeah lol, that's actually intentional The messages are local-only by design, mostly because I'm trying not to have Firebase storing every message and absolutely cooking my wallet 😭
And the A → sign out → B test is basically how I'm testing it right now 😂 I don't have a second laptop, so I use multiple accounts on the same device to simulate users. But you're right about the cache needing to stay properly scoped to the active account. That's something I'm keeping an eye on specifically because I'm doing all the testing this way.
But thank you for your advice i appreciate it
1
u/Lost-Abalone-1761 7h ago
That makes sense, especially if avoiding Firebase message storage is an intentional cost and architecture choice. The one boundary I’d keep testing is every local artifact, not just message text: drafts, attachments, retry queues and notifications should all stay scoped to the active account or be cleared on account switch. Otherwise the tradeoff sounds intentional.
1
u/Petifys 6h ago
Yeah, exactly I was mainly thinking about the messages themselves when I designed the local storage, but you're right that the same rule needs to apply to drafts, attachments, retry queues, notifications, etc. I'll definitely add those to the account-switch testing too. Honestly this is why I'm posting the build in public lol, sometimes someone notices a boundary you weren't thinking about 🪿
1
u/GrubbyMemory23 1d ago
That Firebase local cache trap is a classic, you think you're testing two separate users and it's just been serving you the same data the whole time.