jschr · January 28, 2017 03:36
diff --git a/gistfile1.txt b/gistfile1.txt

 There are a few layers involved in making a realtime app. Still learning the realtime architecture myself but internally, your infrastructure will need to be able to support reacting to updates instantly. That's pretty difficult to do when you have multiple servers and clients making updates while also asking to be notified of those changes in realtime. 

 RethinkDB handles that at the db level. Meaning your web servers can directly ask the database when an update has occurred. Most other databases don't have a way for servers to open a communication channel that allows them to be notified of database changes as they occur. In relational databases you could probably accomplish this with table triggers but I'm not too familiar with using them like that. RethinkDB makes it much easier, and has a cool query language. However in a lot of cases in realtime apps your clients will disconnect and reconnect and will require knowledge of the change log of updates since the last time it was connected. To do that you’d need to have knowledge of which updates were sent to which clients. RethinkDB as far as I understand does not do that. For functionality that relies on that feature you’d likely need a dedicated message queue database like RabbitMQ or AWS’s hosted SQS or Kinesis service. RethinkDB when I looked at it didn’t support transactions either, which are pretty important for a lot of apps. 

 With a message queue, your servers would push a message to a channel after a successful database update. That way all servers can respond to updates as they occur on other servers. This is important for the Websocket layer. Websockets are how the browsers can react to realtime changes. Millions of browsers will open persistent TCP connections, potentially spread out across multiple web servers to send and receive notifications of updates and other events. The websocket layer is a bit more complex than your average REST API. The RethinkDB team built Horizon to do make that easier (basically a self hosted Firebase). Scaling websocket servers is also more complicated than your average REST api. That’s why services like Firebase and PubNub exist, they handle that for you. Firebase is a full on database, message queue and static hosting solution that pretty much acts as 90% of your backend. It makes building MVPs really fast but there are natural tradeoffs when you have a system takes over a large portion of your infrastructure. PubNub as I understand, acts as that scalable WebSocket / Message Queue layer which is a nice middle ground. They have a feature called Blocks which also looks cool, you can provide it javascript code that runs in the server much like AWS Lambda but for WebSockets.

	There are a few layers involved in making a realtime app. Still learning the realtime architecture myself but internally, your infrastructure will need to be able to support reacting to updates instantly. That's pretty difficult to do when you have multiple servers and clients making updates while also asking to be notified of those changes in realtime.

	RethinkDB handles that at the db level. Meaning your web servers can directly ask the database when an update has occurred. Most other databases don't have a way for servers to open a communication channel that allows them to be notified of database changes as they occur. In relational databases you could probably accomplish this with table triggers but I'm not too familiar with using them like that. RethinkDB makes it much easier, and has a cool query language. However in a lot of cases in realtime apps your clients will disconnect and reconnect and will require knowledge of the change log of updates since the last time it was connected. To do that you’d need to have knowledge of which updates were sent to which clients. RethinkDB as far as I understand does not do that. For functionality that relies on that feature you’d likely need a dedicated message queue database like RabbitMQ or AWS’s hosted SQS or Kinesis service. RethinkDB when I looked at it didn’t support transactions either, which are pretty important for a lot of apps.

	With a message queue, your servers would push a message to a channel after a successful database update. That way all servers can respond to updates as they occur on other servers. This is important for the Websocket layer. Websockets are how the browsers can react to realtime changes. Millions of browsers will open persistent TCP connections, potentially spread out across multiple web servers to send and receive notifications of updates and other events. The websocket layer is a bit more complex than your average REST API. The RethinkDB team built Horizon to do make that easier (basically a self hosted Firebase). Scaling websocket servers is also more complicated than your average REST api. That’s why services like Firebase and PubNub exist, they handle that for you. Firebase is a full on database, message queue and static hosting solution that pretty much acts as 90% of your backend. It makes building MVPs really fast but there are natural tradeoffs when you have a system takes over a large portion of your infrastructure. PubNub as I understand, acts as that scalable WebSocket / Message Queue layer which is a nice middle ground. They have a feature called Blocks which also looks cool, you can provide it javascript code that runs in the server much like AWS Lambda but for WebSockets.