[_m8fo]

I've only skimmed the article (as of yet), but how is this superior/better than just a dedicated server plus DB for messaging with a simple READ(all), REPLY(to_message) API?

This seems like an interesting technical problem, but I can't help but feel that there's a significantly easier solution available. As a bonus: other than the fact that you can see messages in the app, I wonder how this is better than simply using SMS or a personalized anonymous email address per host-guest pair.

I've seen variants of this particular problem solved so often I'm surprised there's no open source back-end/platform that solves the back-end piece of this.

disclaimer: I haven't worked with anything on this scale, personally.

[toast0]

Read all is simple, but is going to use a bunch of data. With a sync api, they cam justify doing small transfers as they happen (if connectivity is available), so the data is already there when you go to read it. Even if there's no background sync, sync on use can be faster to download than a full load on use, and you may be able to display the stale data while validating.

[lucasmullens]

Sending an SMS costs money, and for many users email isn't as reliably seen as something like an app push notification.

[_m8fo]

I was referring to what huangc10 suggested with letting users communicate "offline" via SMS. I'm also skeptical that email is less reliable than an app push notification. The post itself even suggests that before they made adjustments to their messaging system there were some unreliability. I'd think that the use of email in the way outlined in the post is a pretty "solved problem".