I have couple of questions related to building high-scalable REST-API is scala domain.
What is the recommended way of building high-scalable REST-API , spray.io or PLAY2-MVC
Since Spray.io is getting converted to Akka-http, we have double mind on using the spray-library
Is Play.MVC.Controllers actor based system, coz I don;t see actor reference in the class
trait Controller extends Results with BodyParsers with HttpProtocol with Status with HeaderNames with ContentTypes with RequestExtractors with Rendering
Thoughts please
Play is a full stack framework (similar to RoR, but without many of the weakness's that RoR has). Play (by far) has the best support for client side tooling (i.e. stuff like coffee/less/require.js integration)
On the other hand, if you are strictly doing an API, akka-http/spray may be a better choice.
Akka-http is easy to understand and is quite scalable , so I would recommend using Akka-http.
For the answer of your third ques: Yes Play is itself built on akka : How is Akka used in Play?
For more info you can see this reddit page where many have given it a try: https://www.reddit.com/r/scala/comments/3qyg2m/which_should_i_use_to_build_my_restful_api/
Related
I need to build REST API for my services and I am new to Scala. I have come to know of finatra and akka-http. After studying for a while, I am more inclined towards finatra as it offers java-style syntax and methodology for web services. However, akka has a very close knit relation to scala and learning akka-http at this point might help me in my scala journey.
Any help is appreciated.
They are on very different levels, akka-http is mainly a http server / client with very raw implementation and finatra is framework with modules, dependency injection, you get an administration view and page, flags and configuration. Finatra is the way to go if you like to have a more functional library then have a look at Finch https://finagle.github.io/finch/
I have to build a component that runs in a jvm, uses MongoDB as database and doesn't need a UI. It will be integrated into other products. I'm planning to build this using scala and related tools.
My first thoughts are to just let it expose REST API and let other products integrate using the API. While this is acceptable for some products, it isn't for others due to performance reasons. So I have to enable other components to communicate to this using either http or ipc or message queues. How can achieve this without much duplication of business logic.
Would Play framework be the right choice for this even though there is no UI involved and there is a need to accept messages via http or ipc or message queues?
Using Play for that is ok but there are frameworks better fit for what you are planning to do, as you already said, play has a lot of support for frontend features you don't need.
It will not so much affect the runtime speed as the time you will need for programming, compiling, building and deployment.
There are some framworks that might fit you needs better:
Scalatra Nice, easy to use, integrates good with JavaEE-Stack http://www.scalatra.org/
Finatra Cool if you have the twitter stack running. Metrics and other stuff almost for free http://finatra.info/
Skinny Framework : Looks nice, never tried myself
Spray : Cool features to come, a little elitist
I have an API service implemented in a Play 2 App, Currently the api handles 5-7000 requests per second on 5 servers. I have benchmarked Spray.IO and Play2 recently and see almost 3x the performance on simple http requests.
I would prefer not to re-implement everything in Spray, if instead I can somehow embed the spray HTTP server in my Play app, than use that to server http requests.
Is this possible? and is there an example of this out there?
I can say that Spray actually is the fastest JVM-based toolkit for web-based development, you can check out the latest benchmarks on the official blog.
As for the question. If you want to write your own implementation for a little HTTP server then you should check spray-can http based api, spray-io is just a layer between Akka IO and Java NIO. I'm not very good at Play, but as a way i would sugest to create a multi-build sbt config or separate project with Spray http server and connect them through REST api.
Architecture would be pretty simple cause it's based on Akka actors in the simplest case would look like a bunch of cases in the receive method:
def receive = {
case HttpRequest(GET, Uri.Path("/ping"), _, _, _) =>
sender ! HttpResponse(entity = "PONG")
}
On the Play side you should use Akka or Play's routing file for describing routes.
Also check out Spray routing api. It's much easier to implement and to use and looks very similar to what Spray can give you with route file, but more flexible and readable.
Also Spray has many great very detailed examples on their Github repo: spray-can and spray-routing.
BTW Spray team also made available Play template engine for front-end and called it Twirl so porting your application to Spray won't take much time
We see that Play rates well for a full stack framework:
http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db&c=1&d=2&a=1
We see that there are trade-offs in terms of developer productivity i.e. the faster you want to go, the less productive your developers will typically be. You need to know whether Play will achieve the performance that your application demands.
Incidentally we have been focused and continue to focus on improving Play's performance.
I hope that this helps.
Actually, The Play framework will soon be using Spray I/O for it's http serverices.
So it looks like you'll be able to have the best of both worlds!
I need to build very concurrent web service which will expose REST based API for JavaScript (front end) and Rails (back end). Web service will be suiting data access API to MongoDB.
I already wrote an initial implementation using NodeJS and would like to try Scala based solution. I'm also considering Erlang, for which every web framework is actor based.
So I'm looking for web framework explicitly build using Actors in order to support massive load of requests I'm very new to Scala and I don't quite understand how Actor might work if almost all frameworks for Scala are based on Java servlets which creates a thread on each request which will just exhaust all resources in my scenario.
If you're really going to have 10k+ long active connections at a time, then any standard Java application server/framework (maybe, except for Netty) will not work for you - all of them are consuming lots of memory (even if any kind of smart NIO is used). You'd better stick to a clustered event-loop based solution (like node.js that you've already tried), mongrel backed with zeroMQ, nginx with the mode for writing into MQ polled by Scala Actors, etc.
Among the Scala/Java frameworks, Lift has a good async support for REST (though it's not directly tied to actors). OTOH, LinkedIn uses Scalatra + stdlib actors for their REST services behind Signal ,and feels just fine.
Another option is Play framework. The latest 1.1 release supports Scala. It also supports akka as a module.
As far as Scalatra itself, they have been working on a new request
abstraction called SSGI (akin to the Servlet/Rack/WSGI/WAI layer),
that they said should ennable them to break from solely running as a
Servlet and also run on top of something built with Netty. See thread here.
http://github.com/scalatra/ssgi
There's some other interesting frameworks at the Scalatra level of simplicity since designed from the ground up to support asynchronous web services (won't tie up a thread per request):
https://github.com/jdegoes/blueeyes - Not a servlet; built on Netty.
("loosely inspired by ... Scalatra")
http://spray.cc/ - Built on Akka actors, Akka Mist. Servlet 3.0 or Jetty continuations
("spray was heavily inspired by BlueEyes and Scalatra.")
And at a lower level:
https://github.com/rschildmeijer/loft - "Continuation based non-blocking, asynchronous, single threaded web
server."
Not production-ready, but rather interesting-looking. Continuations require the compiler plugin.
http://liftweb.net/ Indeed, a request starts off as a servlet, but then lift uses comet support found in many servlet containers to break away from the thread, keeping the request context (which the container then doesn't destroy) which then can be used to output data in actors.
http://akkasource.org also has support for rest, but it will block the thread until the actor finishes with its work
Is there a way to use a webservice (REST in this case) as the data source for a Lift application? I can find a number of tutorials/examples of using Lift to provide the REST API, but in my case the data is hosted elsewhere and exported as a REST webservice. Pointers to doc are greatly appreciated.
Thanks,
Jeff
This is not related to Lift in fact. There is a lot of different pieces of information already:
HttpClient library as was suggested already,
or Dispatch Scala library for accessing HTTP services
information on how to cache data in Scala in various ways in case you need it
Think about caching thoroughly, it is generally a good choice if your application generates a lot of requests and you can afford caching. Caching will let you achieve many goals:
decrease response time, as you do not depend on the remote service (if you do synchronous data processing)
avoid Denial of Service in case the remote service dies. Otherwise your application will generate many sockets to read data and exhaust resources (either sockets or threads or something else)
do not exceed SLA of the remote service, as many services constrain the number of requests you are allowed to pefrorm per some unit of time.
So you can just sit and put these things together, that's it.
If you really want to be fancy, you can create a Record implementation for a REST-based data source. There's already one of these in existence that works with CouchDB. Using the lift-couchdb module, the interactions with CouchDB are abstracted away and all you deal with is the Scala code. There is a short wiki page with instructions on how to get started with lift-couchdb here:
http://www.assembla.com/wiki/show/liftweb/CouchDB
The pertinent source code files are available here:
http://github.com/lift/lift/tree/master/framework/lift-persistence/lift-couchdb/src/main/scala/net/liftweb/couchdb/
Using the Record interface gives you access to lots of Traits which you use to provide functionality with minimal code-writing such as creating HTML forms, providing lifecycle based calls, and easy hooks for validation.
I've put a scala layer over HttpClient and then use that. I've been meaning to put this on github for some time.
I use Dispatch (which is a wrapper around HttpClient) for making REST calls. Looks nice and simple