Note: Unfortunately this question was closed, but I'm trying to maintain it for if someone else comes along with the same question.
I've been looking for a good solution to developing a service in Scala that will sit between mobile devices and existing web services.
The current list of viable options are:
Finagle
Spray
BlueEyes
Akka
Play2 Mini
Unfiltered
Lift
Smoke
Scalatra
There are probably more options out there. How does one decide which one to use? What are the traits (excuse the pun ;-) of a good Scala middleware choice. On the one side, I would like to go for Akka, because it is part of the TypeSafe Scala stack, but on the other, something like Finagle has a rich set of libraries and makes plumbing so easy. Spray looks nice and simple to use.
Any advice, insights or experience would be greatly appreciated. I'm sure someone out there must have some experience with some of these that they won't mind sharing.
UPDATE:
I would love for this question to be reopened. A good answer to this question will help new Scalateers to avoid related pitfalls.
UPDATE 2:
These are my own experiences since asking this question:
Finagle - I used Finagle for a project and it's rock solid.
Spray - In my latest project I'm using Spray and I'm extremely happy. The latest releases are built on Akka 2 and you can run it directly with the Spray-can library which removes the need for a web server. Spray is a set of libraries, rather than a framework and is very modular. The Learn about Spray: REST on Akka video gives a great overview, and this blog at Cakesolutions shows a really nice development approach and architecture.
UPDATE 3:
Life moves pretty fast. If you don't stop and look around once in a while, you could miss it. - Ferris Bueller
These days the choice has become simpler. In my humble opinion Spray has won the battle. It is being integrated into Akka to become the next Akka HTTP. I have been using Spray now on multiple projects and can honestly say that it's fantastic and best supported software I have ever encountered.
This does not answer the initial question, but at least gives some indication on why Spray seems like the best choice in most cases. It is extremely flexible, non-blocking and very stable. It has both client-side and server-side libraries and a great testkit. Also, have a look at these stats to get an idea on performance: Web Framework Benchmarks
I personally started with spray a long time ago and tried everything else there was out there for Scala. While Scala, spray, akka, shapeless, and scalaz certainly have a bit of a learning curve, once you start digging in and really learning how you are supposed to use the technologies, they make sense and I immediately saw the benefits especially for the kind of work I'm doing right now.
Personally I think nothing really stands up to spray for building both servers, rest apis, http clients, and whatever else you want. What I love about spray is that they built with akka in mind. It may have been a really early project when I first started using it, but the architecture made sense. Those guys knew what they were doing in terms of exploiting the benefits of using an actor model and not having any blocking operations.
While actors might take a bit getting used to, I do like them. They have made my systems very scalable and cheap to run because I don't need as beefy hardware as in the past. Plus, spray has that spray-routing DSL so making a rest api is relatively simple as long as you follow the rules ... don't block. That of course means don't go and pull in apache commons http client to make client requests from the api or actors because you will be going back to blocking models.
So far I am very happy with spray, typesafe, and akka. Their models just naturally lend themselves to building very resilient systems that come back up on their own if anything should happen and you take a fail-fast approach. The one beef that I have with spray (and it's not spray's fault) is the damn IDE support for the routing DSL. I absolutely despise Eclipse and have always been an IDEA user. When I started using the Scala plugin, everything seemed ok. Then my routing dsl naturally evolved into way bigger beasts. Something about the way IDEA parses that code makes it shit its pants anytime it encounters anything with spray-routing or shapeless. It's to the point where it's unusable (I type 2-3 letters and have to wait 5 minutes to regain control).
So, for any spray-routing or heavy shapeless code, I fire up emacs with ensime, ensime-sbt, and scala-mode2. Now if I could only get a Cassandra library with the quality of astyanax and built using a more non-blocking architecture.
Here you can find a great list of scala resources with a brief description of all the alternatives you listed.
From my own experience, I use Scalatra and it is tiny, simple and effective for things like uri mapping and calling web services.
Related
I'm going to develop new HTTP/REST services using Scala and Akka Actors.
I have experience working with Play, but I don't really need a complete web Framework.
From what I read, I think Spray is a suitable choice.
My question come from the future of Spray after the new arrived AKKA-HTTP.
Does the Spray project will grow independently from the Akka-HTTP project, or are the two project going to be merged into one Akka-HTTTP?
What is the impact of this if I start developing with Spray?
Also I read that Play will integrate AKKA-HTTP.
So I finally wonder if a should not go with Play?
Thanks for your help.
Spray is production ready, but the development team (Mathias Doenitz) works for Typesafe on Akka-http now.
The status of Akka-http is "development preview". There are vague promises of a full release "within a few months", but nothing you can take to the bank.
Edited 29-July-2015:
The status of Akka-HTTP is now "release candidate" with version 1.0 RC4.
Its functionality is largely competing with spray.io, and the common expectation is that spray.io will lose it's development momentum.
At this time I would not recommend spray.io for new projects anymore.
Jonas Boner from Typesafe has referred to Akka-http as "Spray 2.0". So don't expect any future versions of Spray and at some point you'll have to make the switch. I saw Jonas' Akka-http presentation at Scala Days and it looks like porting Spray code to Akka-http should be straight forward as the DSL is mostly unchanged (even though the underlying implementation of the library will be different).
To answer your questions specifically: Spray is finished as a separate project, it is being imported into Akka under the name Akka-http (not a merge as Akka didn't have any equivalent before hand). If you need to start development now go with Spray, if you can afford to work with the inevitable bugs in a preview release go with Akka-http. Your Spray code will never stop working, but it won't be supported either outside of minor bug fixes. All new functionality will be added in Akka-http, so instead of updating to Spray 2.0 you update to Akka-http.
You have already given answer to your question in your comment. As long as if you don't need to deal with UI I would suggest go with Akka-HTTP or Spray.io.
I don't think you will have impact if you starts with Spray.io as there are many projects running their production environment on Spray.
For more details please refer below link.
FAQ SPray.io
Typesafe Press Release
Thanks
Well, if you have to learn everything from scratch, I would recommend choosing spray - Akka hhtp documentation is really incomplete and a lot of route directives are not implemented yet on akka.http. I started with akka but I was forced to go to spray...
Typesafe gets Spray(ed) | #typesafe
The Akka/Spray integration—named Akka HTTP—will provide an ideal way
of producing and consuming embeddable REST services.
As per Johannes Rudolph
if you want to provide an HTTP interface to (maybe already existing) akka services, then that's what akka-http is for
source: https://gitter.im/akka/akka?at=5874fc9761fac5a03dbe1a6f
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.
Yesterday I read "Scala for the impatient" and I really enjoy the language.
Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.
But for me it is hard to tell what the main differences are. I think both frameworks are great.
The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor.
(I have not much experience, this is just my first impression)
For the security I don't think that is the job of the framework.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Both frameworks are able to compile after you press F5. I like this feature a lot.
Both frameworks are using sbt
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience) Edit There is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
What are the strengths of each framework?
Posting this after spending a week or two with Lift doesn't really
serve anybody's interests. However, I want to spend some time correcting
some mistakes and mis-perceptions.
For the security I don't think that is the job of the framework.
You're dead wrong. Security is the job of the framework. It's critical that security
is done by default rather than relying on each developer to understand every
security vulnerability and make sure every line of code takes that into account.
All we have to do is look at what happened to GitHub
to understand that even the best coders using well known technology
can make a critical mistake.
Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc.
but the developer can dig down as deep as he wants to the HTTP request and deal
with the bytes on the wire.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Lift is very clear about where you need state and where you don't. Lift can support
stateless, partially stateful, and completely stateful apps. On a page-by-page and
request-by-request basis, a Lift app can be stateful or stateless (for example,
in Foursquare, the venue pages are stateless for
search engine crawls, but stateful for browsers that are logged in.) For
more on the design decisions around state, please see Lift, State, and Scaling.
Both frameworks are using sbt
Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment
and about the deploy environment (Java EE container, Netty, whatever). This is important
because it make Lift easier to integrate with the rest of your environment.
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web framework because,
among other things, it multiplexes all the "push" requests on a page through a single request
to the server which avoids connection starvation. How Lift does async is a whole lot
less important because one of the core philosophies with Lift is that we remove the
plumbing from the developer so the developer can focus on business logic.
But for those who care, Lift has the best and lightest weight actors of any framework in
Scala-land. We were the first to break away from the Scala Actor's library and worked
to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors
to flourish.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
This is part of Lift's commitment to security. It's important.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
Lift apps can be as stateful or as stateless as you want. It's your choice and Lift
makes very clear how to make the decision.
Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out
how to serialize state in a secure, scalable, performant way
(because virtually every request on a web
app that recognizes specific users is stateful) should be done in a predictable,
secure way by the framework with reasonable overrides for the developers.
Parting note
Play is a lot like Rails: it's quick to get a site knocked together and it's
based on MVC, so a lot of developers understand it. But Play lacks the
depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you
want quick, easy MVC, then go with Rails and JRuby and write your
back end in Scala (they work together extraordinarily well.)
Lift is a different beast. There's a significant unlearning curve (stop thinking
MVC and start thinking about user experience first that flows to business logic.)
But once you're up the unlearning curve, Lift sites are more secure, highly
scalable, super-interactive, and much easier to maintain over time.
To see what can be done with Play (it can be cool), have a look at the TypeSafe Console
To get going quick with Lift, use a template project.
For a sample of using Mongo with Play, look at Factile.
In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).
Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.
For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.
I'm developing a gateway that will be located between mobile web apps and web services on backend systems. The purpose of this gateway is to protect web apps against changes to backend web service api's, to introduce concurrency, transform messages, buffering, etc.
My proposed architecture is as follows:
Platform independent mobile web apps using PhoneGap (done)
Gateway is a web service using Scala for business logic and ZeroMQ for message passing (new)
Backends are existing web services (existing)
The gateway is purely responsible passing, translation, aggregation, etc. of messages and does not need to keep state or do user authentication at this point - it's simply responsible for being a single interface that knows how to talk to mobile apps on the one side and one or more services on the other side.
I'm strongly considering using Scala as the development language because it seems well suited for this type of application, but what would be the correct architecture for such a Scala service? I looked at frameworks such as Lift and Play and also considered doing a simple "java" based web service and just use Scala as to implement my business logic. I believe strongly in keeping things as simple as possible. I'm wary of complicated setups and thousands of lines of dead code in frameworks that may never be used. On the other side, limiting oneself to a 'role your own' solution and creating a lot of work and having to maintain code that may have been part of existing solutions is also not ideal.
Some things to consider: I'm the architect and developer, but my knowledge of Scala is limited to the first half of "Programming in Scala, Second Edition". Also, my time is very limited. Still, I want to get this right the first time.
I'm hoping that some clever gent or dame will provide me with insights to this type of solution and maybe a link or two to get started quick. I really need to get going FAST, but hope that the experience or insights of another professional could help me avoid pitfalls along the way. Any insights to development environments and tools will also be helpful. I have to develop on Mac (company rules) but will be deploying on Ubuntu server. I'm currently juggling between installs of Eclipse or Idea as IDE's and the scala compiler or sbt for building.
UPDATE
Thanks for all the potential answers below. I had a look at each and every suggestion and all of them have merit. The problem is now to bet on the right horse. Spray is possibly the simplest solution to the problem, but I also found Finagle. It seams like a stunning solution to my problem. I'm a bit concerned that it is built on top of Netty instead of Akka. Does anyone see any problem with that. I was hoping to keep my solution as purely Scala as possible, but Finagle appears to be the most mature of the lot. Any ideas?
It might be worth taking a look at Akka, which provides a lightweight framework for writing concurrent, fault-tolerant applications on the JVM, as well as useful built-in abstractions for writing web services. In addition, the Spray project looks like it could be useful for your purposes, providing HTTP server and client libraries on top of Akka (Although, unlike Akka itself, I haven't used this so myself so can't vouch for it).
If you're using a web service that is purely for other services, then an Akka based service like Spray or Blueeyes is probably your best bet. You can use Jerkson to do the JSON mapping to and from your case classes and use Akka-Camel to link to ZeroMQ.
As mistertim says, Akka is a good option. I'm biased, but I think Lift and its RestHelper is a fantastic way to go also (I've built several APIs for iPhone apps using Lift). Beyond those, I know several people who are very happy with Unfiltered.
Unfiltered is very interesting option if you want to keep it lightweight, as is not a full blown web framework.
To be honest, the documentation can use more detail, but to provide a web service you just write:
object MyService extends unfiltered.filter.Plan {
def intent = {
case req # GET(Path ("/myendpoint")& Params(params)) =>
for {
param1<-params("param1")
param2<-params("param2")
} yield ResponseString(yourMethod(param1,param2))
}
override def main(args:Array[String]) = unfiltered.jetty.Http.anylocal.filter(MyService).run();
}
Very useful if you don't want to use a framework and don't want to mix java/java annotations with Scala (otherwise, you have the usual java solutions)
Still, I would recommend to look into Akka if you think you think actors will fit your problem
If your system is middle-ware and get the things done quickly, then Spray will be a best. Spray was developed on top of Akka. Akka has ZeroMQ support.
in future if you are going to add some other web like module along with your middle-ware, then choosing Lift + Akka will be better because, Lift also provides Spray like web service stuff + it will be easy to start developing other modules.
You can choose SBT as your build, there are some project templates, template generation tools available, so you can get the project build very quickly.
In my experience , SBT + InteliJ Idea works well, have a look on sbt-idea plugin
Spray Project Template
Lift Project Template Generator
For a project I'm using both Scala and Riak (two things I have never worked with before ;) ).
Google searches seem to suggest using Riakki. However, it seems like that particular library hasn't been maintained since 2009 and doesn't even compile on my system. There is a more up-to-date fork on GitHub that does seem to work with more recent Scala versions. But Riakki seems to depend on Jiak, which has been deprecated since february of last year.
Seems like the only reasonable choice would be to use the official Riak Java-library from Scala. That's certainly possible, but I'd like to do things the Scala-way as I'm trying to learn the language. Having to interface with a Java-style API might ruin a bit of the fun. Writing my own wrapper sounds like it will be too much work.
tl;dr: I want to use Riak from Scala. What are other people using?
edit: just found Ryu (can't link to it - annoying limit on amount of hyperlinks per question for new users). Doesn't seem all that mature though.
Stackmob recently opensourced Scalariak.
Scaliak is a scala-ified version of the High-Level Riak Java Client w/
a Functional Twist. It is currently being used in production at
StackMob.
Scaliak is currently feature incomplete vs. the original High-Level
Riak Java Client. What is currently supported are mostly features
being used in production (there have been a few features implemented
and subsequently not used).
There is also Raiku which states that it is async.
I'm in the same bucket - excuse the bad pun - although I have some experience with Scala. I'm thinking of using the official Java client.
When you are toiling up a steep learning curve, you don't need to be dealing with incomplete and potentially wobbly API's. In my experience, using Java API's from Scala is minimally painful.
I think there'll be enough delight in playing with our new Raik toy that we'll forget about whatever un-Scala-ish foibles the Java API inflicts upon us. All the best.
I'm the author of yet another Scala Riak client, simply called riak-scala-client. It is based on Akka and Spray, it is not built on top of the existing Java client, and most importantly it is completely non-blocking.
Check it out at http://riak.scalapenos.com and let me know what you think.
I'm curious what's the "best" way to program RIAs with Scala.
I'm new to Scala and would simply like to know where to start learning. It seems obvious that for web-apps Lift is the perfect choice to be combined with Scala. However from what I've seen so far Lift is not really providing the key to great visuals. Certainly there are hundreds of possible frameworks due to the compability with Java but that's not very helpful.
What would you recommend ?
What is a common set-up ?
Among others I found cappuccino, a very impressive framework.
http://www.scala-lang.org/node/7281
It just seems like Cappuccino is designed for a language named Objective-J. That doesn't sound like great compability to me. Yet somehow they can work together.
http://frothy.liftweb.net/
Well, if you are new to Scala you should probably try Play, because learning a web framework and a new programming language is hard.
Play has a big community and seems to be quite user-friendly (pressing F5 in your browser reloads your code and displays any errors which have occured).
Normally any Java web framework can also be used in Scala, but Play seems to be pretty Scala-friendly.
There are quite a few Scala-specific web frameworks too, but I don't know enough to tell you more about them.
Lift is an powerful and impressive framework, but certainly nothing for beginners.
(I assume "new to Scala" doesn't mean "I programmed in Haskell, ML and Scheme for decades").
Of course it all depends. Personally, I have had no problem starting with Lift even though I’d only used Scala in the REPL before and just for some toying around to get to know the syntax.
It certainly helps a lot if you already know how to use collections in a functional way without explicit loops, so you can read and understand other people’s code more easily. But basically, I’d say it is doable learning both Lift and Scala at the same time even without a background in functional languages. It’s just the collections thing you’ll have to get used to and if you happen to know Ruby (or a language with list comprehensions) you’ll easily understand it.
The Frothy integration has not yet been updated to the newest version of Lift and I don’t know of any site which actually uses it but maybe this is a thing to ask on the Lift mailing list. In any case, I think Frothy only helps you connecting a Lift setup with some Cappuccino frontend but does not provide many wrappers to the Objective-J code, so you’ll still have to write code in Objective-J.
At that point you can ask yourself: Why not write the whole thing with Cappuccino and decide afterwards if Lift integration is actually needed.
Considering Lift alone: You certainly can use Lift with some UI Kit like JQuery UI for the visuals. Lift has many advanced possibilities which make it possible to build complicated web applications but you’ll have to care about the wiring for the visuals yourself.
(And arguably, a stateful, non-MVC (‘view first’) framework like Lift might be better suited for a rich internet application than a pure MVC framework…)