The outbox has to exist somewhere. Instead of a central server like the group chat you could use some sort of distributed storage... but then some node(s) need to be online at all times to deliver asynchronous messages.
Yea. For the real time part of it, which is the coolest part, it would need enough concurrent users to where when you connect from any major city you would see at least a few people broadcasting. This is somewhat why I added the message archiving, initially. So that it didn't seem like a barren, open zone of no broadcasting. But, I think that the archiving of messages is a good addition for other reasons, too, after the fact.
I do like the idea of focusing on launching at a single event, or location first. That's probably the most realistic and feasible way to go about it.
Looks interesting. I see you build on webkit among other things -- what are the messages? json docouments? Any provision for attachments? Any range for size of messages (eg: a 700mb attachment -- would that make sense with this)?
That's how I'd solve the problem. The added complexity isn't even that high, give the application an endpoint to push an attachment into a distributed object store of your choice, submit a message with a reference to the object and persist it the moment the chat message was sent. This could be done with mere bytes for the message itself and some very dumb anycast-to-s3 services in different data centers.
I'm sure I'm skipping over tons of complexity here (HTTP keepalives binding clients to a single attachment host for example) because I'm no chat app developer, but the theoretical complexity is still relatively low.
I thought NATS didn't actually store messages, am I mistaken?
Looking at Wikipedia (https://en.wikipedia.org/wiki/NATS_Messaging) I see that I'm technically right, it's JetStream that does the storage layer - but it's part of the NATS server.
From memory, I really liked the philosophy of NATS but found the nomenclature confusing.
Splitting a resource into multiple parts and embedding in into a single message in order to avoid external storage and the need for locking is an interesting approach, but sadly not an option for me. Nevertheless, I appreciate your response.
As a side project, I have an idea for a particular instant messaging mobile app.
Each message will be tightly coupled to a specific geographic location, fwiw. And messages will be ephemeral, they'll be deleted completely from the server after a few hours (or maybe a week).
So I'm thinking that there'll be a backend API that the mobile apps will use to send/receive messages.
My question is: what kind of technology would you use for such an application? Where would you store those messages?
AFAIK it was intended to support the use case of being occasionally connected to the internet (one author spent a lot of time on a small sailboat in the south Pacific), while maintaining an order of messages.
PS: it's so amazing to see all that people around the world at the same time, on a map. sounds like a new world to explore :P
reply