9 ms·

Scala vs. Node.js as a RESTful back end server (2015)

61 points by zyngaro 11y ago

daxfohl 11y ago
> 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 11y ago
  >"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 11y ago
    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 11y ago
      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.
  - sievebrain 11y ago
    Those aren't the only ways to write thread safe code, just the oldest ways. Also, remember that you can have unexpected re-entrancy at any callback boundary in the fully async model. It is not a panacea.
- forestfortrees 11y ago
  > The absence of async callbacks not only makes the code cleaner 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.
  - daxfohl 11y ago
    > thread management in general 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.
neverminder 11y ago
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#performance-improvements https://playframework.com/documentation/2.5.x/Highlights25#p...) which is pretty good scalability.
- ec109685 11y ago
  Throughout.
  - ec109685 11y ago
    Throughput:)
- merb 11y ago
  Actually I doubt the article is right when it comes to performance. I mean nodejs could be faster than scala for some things, but scala could also be faster than nodejs for other things. It really depends on what you are doing. Working with big lists and manipulate them is definitly faster in scala than in python, node, etc..
- saosebastiao 11y ago
  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-composition-hardcoding-parameterized-parser 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.
lkrubner 11y ago
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.
- pjmlp 11y ago
  I use Subversion daily. I am yet to experience an enterprise customer that has jumped into Git.
  - yareally 11y ago
    > I am yet to experience an enterprise customer that has jumped into Git. 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.
- kazagistar 11y ago
  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.
davnn 11y ago
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 11y ago
  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?
dreamofkoholint 11y ago
The section describing strong typing is pretty weak/vague, and seems to actually be referring to static typing
raquo 11y ago
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 11y ago
  Wow that's a lot of code delegacy there: scala => scala.js => node.js => electron => desktop.
  - raquo 11y ago
    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_coming_soon/ https://www.reddit.com/r/scala/comments/4ftcx4/scala_native_...
    - dk8996 10y ago
      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 10y ago
        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.
softinio 11y ago
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 :)
beders 11y ago
Comparing a web framework with a JVM language is completely pointless. A better comparison would have been: Vert.x vs. Node.js

61 points by zyngaro 11y ago

> 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 11y ago
>"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 11y ago
  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 11y ago
    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.
- sievebrain 11y ago
  Those aren't the only ways to write thread safe code, just the oldest ways. Also, remember that you can have unexpected re-entrancy at any callback boundary in the fully async model. It is not a panacea.
forestfortrees 11y ago
> The absence of async callbacks not only makes the code cleaner 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.
- daxfohl 11y ago
  > thread management in general 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.

neverminder 11y ago

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#performance-improvements https://playframework.com/documentation/2.5.x/Highlights25#p...) which is pretty good scalability.

ec109685 11y ago
Throughout.
- ec109685 11y ago
  Throughput:)
merb 11y ago
Actually I doubt the article is right when it comes to performance. I mean nodejs could be faster than scala for some things, but scala could also be faster than nodejs for other things. It really depends on what you are doing. Working with big lists and manipulate them is definitly faster in scala than in python, node, etc..
saosebastiao 11y ago
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-composition-hardcoding-parameterized-parser 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.

lkrubner 11y ago

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.

pjmlp 11y ago
I use Subversion daily. I am yet to experience an enterprise customer that has jumped into Git.
- yareally 11y ago
  > I am yet to experience an enterprise customer that has jumped into Git. 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.
kazagistar 11y ago
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.

davnn 11y ago

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 11y ago
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?

dreamofkoholint 11y ago

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

raquo 11y ago

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 11y ago
Wow that's a lot of code delegacy there: scala => scala.js => node.js => electron => desktop.
- raquo 11y ago
  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_coming_soon/ https://www.reddit.com/r/scala/comments/4ftcx4/scala_native_...
  - dk8996 10y ago
    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 10y ago
      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.

softinio 11y ago

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

beders 11y ago

Comparing a web framework with a JVM language is completely pointless. A better comparison would have been: Vert.x vs. Node.js