Centrifugo – real-time messaging server migrated from Python to Go
github.com
github.com
1) how was your experience of changing the code from Python to Go, did it feel ok or have you had major headaches?
2) Why didn't you choose Elixir, there are already massively scalable messaging servers in Erlang and it looks like the best choice for a project like this?
Thanks!
1) It was very interesting and challenging sometimes. I remember several difficulties during migration: many usages of interface{} values at first stages which then be replaced with more strong types, several possible races which Mr Klaus Post (https://github.com/klauspost) helped to find, he also noticed at some problems in code style and channel buffer overflow problem. But the greatest part of this migration is that I don't need anymore think "Is library I use non-blocking or not?" as Go's built-in concurrency allows to use all libraries written for language. And also after Tornado it's great to have tools to inspect active goroutines. I also personally don't like how many locks I use at moment - I hope to refactor several parts of code to use channels for synchronization.
2) Elixir is great, but unfortunately I had no experience with it - just read several articles. Centrifugo is not massively scalable at moment - it does not support Redis cluster yet - this is an area for investigating. So now it is limited to Redis throughput and suites well for small or medium projects. So the answer here: Erlang is absolutely great for software like this but I have chosen a language in which I could implement all that needed in a reasonable time. Go has also its unique features so at moment I am pretty happy that I started migration.
Internally the go scheduler does lots of clever stuff with events but you as the programmer don't have to worry about it.
go routines are very light weight - you can have 10 or 100 thousand easily so this is a very efficient way of running servers with lots of connections.
It is also very easy to program - it is much easier to reason about one thread per connection than to reason about asynchronous event handling.
Question, I notice that if I submit test msgs, it all works and displays in the development project area. However, if I open a new browser tab and navigate to the same project, i dont see the history?
I'm looking to use this for deployment purposes. I can have the window open initially but what if a user decides to join our deployment process a few minutes later? he/she won't see what had happened.
The goal of Centrifugo is just to deliver messages instantly to all connected clients. It has channel history which can be used to show last N messages from channel but it's not related to what you see in web interface. Also note that Centrifugo is not a persistent storage and channel history messages will expire after configurable timeout. So it's possible to implement what you want using channel history but if you take into account 2 things: message history is limited to N messages and message history will expire after M seconds.