
Scala vs. Node.js as a RESTful back end server (2015) - zyngaro
http://developers.redhat.com/blog/2015/04/22/scala-vs-node-js-as-a-restful-backend-server/
======
daxfohl
> JVM provides a great deal more APIs for creating and handling threads and
> processes. Not something you would typically do directly in many webapp
> backends but there if you need it.

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.

~~~
xiaoma
> _" It's a premature optimization that makes coding and debugging more
> difficult."_

Going multi-threaded and dealing with semaphores and mutexes also makes coding
and debugging more difficult. It's all about trade-offs.

~~~
qihqi
Generally true. Though, in context of webapps, each thread usually works on
one request. If your threads share (mutable) states in that case then
something is VERY broken.

~~~
daxfohl
Kind of, but consider logging. In node you can just console.log. In JVM you
have to use a multi threaded logging library or your logs could be jumbled.
Lots of things like that.

------
neverminder
I work with Play Framework
([https://playframework.com](https://playframework.com)) which is probably
most well known scala MVC framework out there. Now I don't know about node.js
based backends, but apparently Play can do 60K requests per second out of the
box
([https://playframework.com/documentation/2.5.x/Highlights25#p...](https://playframework.com/documentation/2.5.x/Highlights25#performance-
improvements)) which is pretty good scalability.

~~~
saosebastiao
I've also been working with Play Framework and I'm pretty impressed at how
awesome and easy to use everything is. The documentation is great, the
performance is great.

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...](http://stackoverflow.com/questions/36683676/play-action-composition-
hardcoding-parameterized-parser))

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.

~~~
yareally
> " _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_"

Have you tried Spray? It still uses akka for actors, but I consider it easier
to use than akka-http.

[http://spray.io/](http://spray.io/)

~~~
ARussell
For some reason I've been thinking that Akka HTTP is basically Spray 2.0. Is
that not right?

~~~
yareally
You're correct. Spray is being deprecated for akka-http and is really "spray
2.0."

------
raquo
I like the storm of Scala.js comments on the article. It's definitely game-
changing for the Scala ecosystem. You can run Scala on node.js now, and by
extension you can package desktop apps written 100% in Scala.js using
Electron.

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.

~~~
galistoca
Wow that's a lot of code delegacy there: scala => scala.js => node.js =>
electron => desktop.

~~~
raquo
Building cross-platform apps with the same codebase is gonna be ugly one way
or another. This particular method is interesting to me personally because I'd
rather depend on node.js than Oracle's 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_...](https://www.reddit.com/r/scala/comments/4ftcx4/scala_native_coming_soon/)

~~~
dk8996
I am not sure what makes you trust node.js (V8) more than the JVM. The JVM has
been in solid for a long time, has higher performance, and more stable. The
JVM GC is very good and highly-tunable.

~~~
raquo
Either of those technologies is good enough technically for my purposes.

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.

~~~
dk8996
The Java ecosystem is fairly complex and it's hard to understand. Your
statement of "Oracle essentially has a monopoly on Java" is not true,
considering Java language is used to built Android apps, runs on diff VM and
uses different bytecode -- outside the control of Oracle (about 2M andorid
apps and 1.6B phone sold). Another thing to consider, the JVM is an open spec
and most of it is open sourced, see OpenJDK. There is also many
implementations of the JVM, see;
[https://en.wikipedia.org/wiki/List_of_Java_virtual_machines](https://en.wikipedia.org/wiki/List_of_Java_virtual_machines)

~~~
raquo
Indeed, I don't have a good understanding of the JVM ecosystem. However:

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.

------
lkrubner
I can remember when Git began to replace Subversion, but a lot of companies
resisted the trend, because Git was so radically different. Subversion was
comfortable: everything was centralized, and the revision numbers went up in
an orderly fashion: 1, 2, 3, 4, 5, 6... You always knew where you were in
history, with Subversion. It was clear that Git was better in some fundamental
way, and yet it took effort to understand it, conceptually, at first.

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](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.

~~~
kazagistar
I have a question I have been trying to figure out for a while. All the
examples of clients that use GraphQL seem to be javascript; is there any
support for writing, for example, a Java client to talk to a GraphQL backend?
This would really help make it easier to port infrastructure over piece by
piece.

~~~
e1g
GraphQL defines the query language, but uses simple HTTP as the transport.
It's not like like redis or mysql - those use custom protocols and so require
special clients to use them. GraphQL backends are like Elasticsearch backends
- you access them by hitting the exposed HTTP endpoint with your query in
plain text. You could do this with any HTTP client library in any language, or
even with curl.

~~~
kazagistar
Thats true, but in a typed, structured language, you generally build some kind
of data structure to deserialize responses into. With REST endpoints, each
response can be translated to a specific predefined object in a client
library. GraphQL seems to, by design, ignore this kind of usage in favor of
the "heterogenus untyped dictionary responses"... do I really have to write
custom data types for every single different query?

~~~
e1g
I think get this now - with SOAP/RPC/REST we can establish the interaction
contract by explicitly defining inputs and outputs. With that contract, we can
draw clearly defined system boundaries, give better assurances to the
developer that they are doing the right thing, and improve testing.

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).

------
beders
Comparing a web framework with a JVM language is completely pointless.

A better comparison would have been: Vert.x vs. Node.js

------
dreamofkoholint
The section describing strong typing is pretty weak/vague, and seems to
actually be referring to static typing

------
davnn
I mostly agree. Should almost always be a project specific decision in my
opinion. If you know that you will not scale to size XYZ than maintaining a
backend based on Scala is just not worth it.

~~~
hhandoko
I agree on best tool for the task at hand, however can you elaborate on your
second comment?

Why do you think a Scala backend can be more trouble than it's worth?

------
softinio
Javascript eco system is so funny overnight its become a kind of compiled
language :-)

Now you can choose the language you like and transpile to Javascript.

I like it though. Especially as Scala and Scala.js are phenomenal :)

