Scala vs. Node.js as a RESTful back end server (2015)
developers.redhat.com
developers.redhat.com
You might not need it directly, but under the hood it allows each request to run in its own thread, which eliminates the need for asynchronous callbacks that pollute any node.js code. The absence of async callbacks not only makes the code cleaner, but also means that when you're debugging and hit a breakpoint, you can follow the call stack all the way back to the request entrypoint.
"Asynchronous Libraries" is listed as a pro for Node, but unless you're doing something very IO-intensive at 10K req/sec, asynchronicity is not going to matter one bit on the JVM since it's multithreaded. Going from sync to async at 10K req/s will save you a few MB of RAM, that's all. Assuming you've got that few MB to spare, it won't change your throughput or responsiveness at all. It's a premature optimization that makes coding and debugging more difficult. I'd rather state this as "Needs Async Libraries" as a con for Node.
Going multi-threaded and dealing with semaphores and mutexes also makes coding and debugging more difficult. It's all about trade-offs.
Also, remember that you can have unexpected re-entrancy at any callback boundary in the fully async model. It is not a panacea.
I agree async callbacks are not very pretty. However, neither is dealing with shared state between threads, or doing thread management in general. Personally I will take the ugly callbacks over buggy/unsafe thread management any day.
> The absence of async callbacks not only makes the code cleaner, but also means that when you're debugging and hit a breakpoint, you can follow the call stack all the way back to the request entrypoint.
Look for the "async call stack" in the v8 debugging tools. This lets you follow async callbacks around like a normal call stack.
> I'd rather state this as "Needs Async Libraries" as a con for Node.
Again, having a single-threaded run loop avoids entire classes of problems (like shared state), which is a huge plus in many cases.
That's the beauty of it though; the JVM web server does the thread management so your app code doesn't have to deal with it at all.
> avoids entire classes of problems (like shared state)
Shared state is an orthogonal thing though. You can have shared state in Node or go stateless in Scala. You can have race conditions in either. Node prevents the simple `shared.x = shared.x + 1` problems, but can't ensure anything across callback boundaries. Scala attacks this by making everything immutable by default. Either way, there shouldn't be shared state in a REST app anyway.
> "async call stack"
That is pretty cool. Actually once Javascript gets async/await added to core, then Node could be pretty viable.
Working with big lists and manipulate them is definitly faster in scala than in python, node, etc..
I'm using it for just a web API, and I've had several scala developers tell me to use akka-http instead because it is simpler. I tried, but the route api is quite horrid in comparison to a simple file-based routing description, and the utilities (like the web service client) were a nightmare to work with and debug. And to top it off, the performance was still worse than play. Maybe all of that will get better, but as of right now, Play is hard to beat.
My only complaints so far:
1) Slick is bloated and kludgy and still produces bad SQL queries...I've resorted to using the plain SQL interface which is nice, but not great.
2) It could use some support for API description languages like swagger.
3) Testing your code using the dependency injection framework has been very unintuitive (I'm pretty new to dependency injection frameworks though, so maybe it's just me).
4) Action composition has been a lot harder than expected (for example: http://stackoverflow.com/questions/36683676/play-action-comp...)
5) I wish I didn't have to deal with an opaque SBT plugin, and that the project just used a regular SBT project structure. I realize there are reasons for needing a plugin (like codegen for routes, etc.), but at least document how to work with the plugin better. SBT is like working with a black box as it is, no need to make it worse.
Have you tried Spray? It still uses akka for actors, but I consider it easier to use than akka-http.
You could check out quill [1]. Haven't used it in a real application yet but the codebase seems easier to understand and the sql it produced seemed reasonable. virtualwhys could probaly tell you more - if I remember correctly he is a contributor for quill (and was/is (?) a longtime user of scalaquery/slick).
On (2): There is a number of Play Swagger plugins (e.g. https://github.com/swagger-api/swagger-play), each with different approaches.
On (3): DI can actually be quite practical. Use different implementation via configuration (bind at startup), use fakes for testing, benchmark two implementations before swapping them, etc. Develop to an interface, not to an implementation :)
PS. I have a Play 2.3 app already in production, 2.4 currently in development, and plan for a new app on 2.5. I'm upgrading from the oldest one first...
>LinkedIn is a prominent user. Their entire mobile stack is built on Node.js. They went from running 15 servers with 15 instances on each physical machine, to just 4 instances – that can handle double the traffic!
>eBay launched ql.io, a web query language for HTTP APIs, which uses Node.js as the runtime stack. They were able to tune a regular developer-quality Ubuntu workstation to handle more than 120,000 active connections per node.js process, with each connection consuming about 2kB memory!
I'm just starting to fiddle with it, but Scala.js on both the backend and frontend seems like a great combination – lets you use the same language and packages throughout your application, and frees you from the JVM.
It's worth mentioning that Scala might get a native backend soon, partly built on the same infrastructure as Scala.js – that could give you a migration path from node.js/Electron to a truly native app with a simple WebView for UI. See https://www.reddit.com/r/scala/comments/4ftcx4/scala_native_...
However, I have much more confidence in node's new governance (and therefore its bright future) than in Oracle. Oracle essentially has a monopoly on Java. And they're not nice guys. I don't feel comfortable building a cross platform application on Java no matter how much momentum it has gained historically.
Google is tentatively on the hook for $9B for... essentially implementing its own JVM... or something. Doesn't matter to me, end result is that the future of Java on Android is far from clear. They're allegedly looking into using Swift as the next generation Android language.
RoboVM, one of the better / more popular ways to write iOS apps in Java was close-sourced, then acquired by Xamarin, then Microsoft, then shut down.
Oracle charges licensing fees for using JVM in embedded devices and kiosks.
To summarize, there's an incredible amount of tools and libraries for Java, but I don't like where Java's mobile story is going in general.
As far as I know the number of viable JVM machines you could build a business on is maybe... 5 at most? They're all experimental and/or abandoned.
Meanwhile, node / JS / ASM.js / Emscripten and friends are only getting better, faster and more widespread outside of the web.
I feel like the same thing is happening now with GraphQL versus REST. On some level it seems like GraphQL is altogether better than REST, but we don't see a mad rush to adopt GraphQL, because it represents a big shift in thinking, and those of us who just spent the last 10 years creating RESTful interfaces, we are a bit slow to throw out all of our work and start over with GraphQL. Also, the frontend needs to change as much as the backend, so it requires a full re-write of everything.
All the same, a title like "Scale vs. Node.js as a RESTful back end server" does strike me as an anachronism in 2016. Who cares? I doubt I will ever again build a RESTful interface. Rather, on the project I'm working on right now, we are getting rid of the RESTful interface and we are looking at our GraphQL options:
https://github.com/chentsulin/awesome-graphql
Is Scala or Node.js the best option for building a GraphQL server? That would be an interesting article.
You're right - in the scale of app-level problems, GraphQL is just a low-level protocol. It requires language-specific libs to address these higher-level problems (provide interfaces, structs, query typing, etc). As a very basic example, programatically building a GraphQL query is unnecessary complex outside of JS because many languages don't yet have a QueryBuilder for the GraphQL syntax. There are some community efforts, but as of yet no heavy corporate players to drive GraphQL-specific dev (e.g. like Pivotal/Sensio/Sencha did for their respective fields).
My company recently did (1000+ employees), though from what I've seen, many of my coworkers familiar with only svn are still using git like svn. We also have a lot of legacy code still within svn (various reasons outside of my team's control), so the transition is pretty messy IMHO.
A better comparison would have been: Vert.x vs. Node.js
Why do you think a Scala backend can be more trouble than it's worth?
Now you can choose the language you like and transpile to Javascript.
I like it though. Especially as Scala and Scala.js are phenomenal :)