7 ms·

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 kn

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.
- neverminder 11y ago
  Yes there are issues, but what framework doesn't have them? I am too annoyed by 22 element tuple limit in context of slick and other stuff, but when you look around there are no better alternatives without major downsides. Try to find a decent framework written in functional strictly typed well scalable language and you end up with Play.
- yareally 11y ago
  > "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 11y ago
    For some reason I've been thinking that Akka HTTP is basically Spray 2.0. Is that not right?
    - yareally 11y ago
      You're correct. Spray is being deprecated for akka-http and is really "spray 2.0."
- redtuesday 11y ago
  > 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. 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). [1] http://getquill.io/ http://getquill.io/
- hhandoko 11y ago
  Just a couple of comments: On (2): There is a number of Play Swagger plugins (e.g. https://github.com/swagger-api/swagger-play 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 :)
dk8996 11y ago
I have used Play Framework in production and its really good -- I really hope there is more adoption like we have seen with Node or Rails. The only complaint, is that there have been big changes from 2.0 to 2.5. Moreover, the documentation on the site is just OK, examples in the community can be out of date, and books are out of date as well.
- hhandoko 11y ago
  What do you think of upgrading incrementally via each minor versions (e.g. 2.0 -> 2.1 -> 2.2, etc.)? It will be easier to reason (and debug) the changes between each version, and test compatibility on the dependent libraries. 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...
  - dk8996 11y ago
    Upgrading minor versions is the way to go. It still seemed like a pain to upgrade since Play Framework has changed quite a bit in the 2.X branch -- more than you would think. I am not trying to trash Play Framework since when you get it up and running its simple the best. I'm a big fan of the JVM.
bluebknight 11y ago
Some perf numbers from Google. >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!

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.

neverminder 11y ago
Yes there are issues, but what framework doesn't have them? I am too annoyed by 22 element tuple limit in context of slick and other stuff, but when you look around there are no better alternatives without major downsides. Try to find a decent framework written in functional strictly typed well scalable language and you end up with Play.
yareally 11y ago
> "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 11y ago
  For some reason I've been thinking that Akka HTTP is basically Spray 2.0. Is that not right?
  - yareally 11y ago
    You're correct. Spray is being deprecated for akka-http and is really "spray 2.0."
redtuesday 11y ago
> 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. 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). [1] http://getquill.io/ http://getquill.io/
hhandoko 11y ago
Just a couple of comments: On (2): There is a number of Play Swagger plugins (e.g. https://github.com/swagger-api/swagger-play 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 :)

dk8996 11y ago

I have used Play Framework in production and its really good -- I really hope there is more adoption like we have seen with Node or Rails. The only complaint, is that there have been big changes from 2.0 to 2.5. Moreover, the documentation on the site is just OK, examples in the community can be out of date, and books are out of date as well.

hhandoko 11y ago
What do you think of upgrading incrementally via each minor versions (e.g. 2.0 -> 2.1 -> 2.2, etc.)? It will be easier to reason (and debug) the changes between each version, and test compatibility on the dependent libraries. 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...
- dk8996 11y ago
  Upgrading minor versions is the way to go. It still seemed like a pain to upgrade since Play Framework has changed quite a bit in the 2.X branch -- more than you would think. I am not trying to trash Play Framework since when you get it up and running its simple the best. I'm a big fan of the JVM.

bluebknight 11y ago

Some perf numbers from Google. >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!