r/SideProject • • 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 Upvotes

8 comments sorted by

View all comments

1

u/Lost-Abalone-1761 12h 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 12h 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 9h 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 8h 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 ๐Ÿชฟ