7 ms·
Thoughts about the cutting-edge of server programming
I am currently working on a project to develop a secure mobile app using micro-services written in Go, Node.js, and Lua targeted at both Android and iOS. I am writing the back-end which will be cloud-based. I thought it would be a good idea for me to share some of my experiences.
Micro-services are the coming absolute standard in server architecture. Dividing a program up into smaller pieces has always be one of the principles of computer science, but to take it one step further and to have different parts of the program in different machines use to be only in the realm of super-computing. Cheap cloud-computing allows everyone to easily create their own clusters, and micro-services are the best architecture.
Of course our queries are RESTful, but we chose to use a simplified form. The requests are URL-queries, and it seems that the lowest common denominator for how long they can be is 2k characters (to be accessible to all browsers). The responses, though, are always in JSON.
Go is an incredible language whose standard library has enough components to satisfy 90% of one's needs. One can think of it as an improved C, so it lacks inheritance, function overloading, and generics. I hope someone creates a fork called Go++. I did some tests, the Go HTTP component was 80% as fast as Nginx, but they were only simple page loads, since Nginx's scripting language is not that complete.
Node.js is the most powerful way to do server-side scripting. Tens of thousands of packages means that one hardly has to write any code. And the speed is pretty decent, but do not even try to do anything CPU intensive. Node.js is JavaScript which is compiled with the V8 Engine and single-threaded.
I also realized the differences between concurrency and parallelism. When there is only 1 CPU, it is not possible to have parallelism. Parallelism includes concurrency, but concurrency is not parallel.
- anonyfox 11y ago> Node.js is the most powerful way to do server-side scripting not really. By the way, have a look at http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-... . Elixir/Erlang excels at concurrency and allows you to build large-scale distributed backends easily, with many additional benefits (fault tolerance, ...).By the way, "Microservices" and "Actors" for parallelism and concurrency aren't really discussed in the erlang/elixir world, since this is the natural way to code. The "cutting edge" to do massive backends is actually decades old, battle-proven and guaranteed to work, this is what erlang actually was designed for. Many many Big systems today are using the Erlang VM for their critical backends, like Call of Duty or Whatsapp.
- vezzy-fnord 11y agoPlease do not give undue preference to Elixir over Erlang. Other than that, I agree.
- anonyfox 11y agoI used both, Elixir/Erlang and Erlang/Elixir. And Both variants exactly one time. The only small preference is that I used the Elixir/Erlang variant as the first one, but hey, one could argue that coming from Go/Node, elixir may be easier to get started. :)
- vezzy-fnord 11y agoWhat are "Elixir/Erlang" and "Erlang/Elixir" supposed to mean? I understand adding the slash for OTP, as those are shared traits. Perhaps their use of BEAM, though that's secondary.
- anonyfox 11y agoCommon language shortcut for "OR", at least for my understanding it seems-
- RaitoBezarius 11y agoI think that the Go++ you search exists already: Rust. (no offense, but Rust has everything you need plus what Go has already)
- anonyfox 11y agoAgreed, Rust is superior to Go in almost any way. Especially when stuff becomes more than a 30-lines-snippet, Rust shines.
- necaris 11y agoI haven't yet found a supported Rust answer to goroutines, though -- am I missing something?
- RaitoBezarius 11y agostd::uv ? lightweight threads similar to go-routines, greenlets of gevent (Python), or Node.js. EDIT: Mea culpa, it used to have. (ref. http://stackoverflow.com/questions/29428318/why-did-rust-remove-the-green-threading-model-whats-the-disadvantage http://stackoverflow.com/questions/29428318/why-did-rust-rem...) Well, you can always build your own interfaces to achieve a similar result. But why do you need go-routines ? By the way, at least, Rust tries to handle concurrency the most he can (by analyzing if data race can occur, at compile-time for example). What do you need more ?
- necaris 11y agoThe goroutine model allows a lot of tasks to be handled in parallel without the application developer having to worry about it. So, for example, a web framework can have one goroutine per request and scale very well. That is what I would love to see in Rust, although I know it isn't likely right now since a lot of the ecosystem is still maturing.
- RaitoBezarius 11y ago
- JustSomeNobody 11y ago"Micro-services are the coming absolute standard in server architecture." I worry when I read comments like this. Micro-services are an architectural style that should be used appropriately, not religiously, no matter what your favorite blog is telling you.
- sheepmullet 11y agoSpot on. And there is a fairly large overhead. A lot of the places speaking about the wonders of micro-services deal with <100 micro-services (about the number you would get if you converted a small-medium sized app). Lets see what happens when you get 10k micro-services.
- josep2 11y agoHi, you mentioned Lua in the first paragraph but didn't go into any detail about how you are using it. Can you expound on that?
- stephenr 11y ago> Tens of thousands of packages means that one hardly has to write any code. this is exactly what's wrong with the Node community.
- VOYD 11y agoI'm curious if you writing a "mobile app" that works in the browser, why you labelled it Android/Ios? I do love the optimism abound that you think your app will need to scale so largely. It is better to build in scale from the beginning, rather than as an afterthought.