The Vert.x documentation says that Scala (and Clojure) will be supported 'soon'.
What's actually missing for using it with Scala as is??
So, as of 2013/11/04:
Scala support has everything up to Vert.x 2.0.2-final plus DNS support. So you need 2.1M1 of Vert.x core and the 0.2.0 release of Scala.
We need to add UDP support, EventBus timeouts (mostly done, but there seems to be a bug in the vert.x core project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420850 ), provide asynchronous registerHandler methods (as these changed to async style) and provide a solution for the unregisterHandler problem we were facing (probably use the asynchronous registerHandler to provide a RegisteredHandler object that has an unregisterHandler() method).
and a followup
Update: EventBus timeouts are done, waiting for review in pull request https://github.com/vert-x/mod-lang-scala/pull/77
I forgot to mention that HTTP Compression was also missing. Just added another PR to review here: https://github.com/vert-x/mod-lang-scala/pull/78
Also added docs for both of them.
To recap what's still missing:
UDP support + test + docs
asynchronous registerHandler methods + test + docs
unregisterHandler issue + tests + docs (I guess this should be done with the asynchronous registerHandler providing a AsyncResult[RegisteredHandler] => Unit callback)
Also announced today:
I'm really proud to announce the release of Vert.x Scala 0.2.0 which includes full Vert.x 2.0 API support as well as new DNS API support coming up in Vert.x 2.1. This means that mod-lang-scala 0.2.0 now requires Vert.x 2.1.
The amazing API work has been driven by the tireless Joern Bernhardt and his colleague Sascha Schmidt. Between them two they've added all the missing APIs and reworked the testsuite to add Scala specific testtools. This was a big tasks and both Joern and Sascha deserve full credit for pulling this off. Kudos to both for this fantastic work!! :). On top of this, we've also added the capability to deploy Scala scripts into Vert.x, bringing the Vert.x Scala examples in line with other languages.
For next release, 0.3.0, we'll be focusing on polishing some these APIs, adding new APIs that Vert.x 2.1 brings, documentation and more examples :)
While we complete the documentation, the best place to get started with the Scala language module is to look at the README file in the Vert.x mod-lang-scala repository.
Related
I am working on my graduate thesis about RESTful web services in Spark micro framework and I want to talk a little about HTTP 1.1 protocol specifically HTTP methods. Problem is I am a bit confused with the reference documentation cause till now in my graduate thesis I've used HTTP 1.1 RFC2616 as my reference documentation but I see that there is a lot of new updated versions like RFC7230 and I am confused which one is the current one that is used. I am currently using jetty-9.4.4.v20170414 as my server and I can see that the server uses HTTP 1.1 but I am not sure if I am describing the right version of HTTP used in my jetty server?
2616 has been obsolete since June 2014, when they released 723x. Each of 7230-7235 have a section at the end that describes what changes there are since 2616. I can't speak to what's being used in Jetty, but there are not many substantiative changes between the documents, so if that version of Jetty is relatively recent, I'd expect it conforms to the new specs. Have you tried asking the Jetty authors?
I want to use REST async client callback, meaning the server is causing a callback operation to be invoked on the client side when a response is ready (see Jersey's 'Asynchronous Services and Clients' to get what I mean)
Can I express this in Swagger/RAML/anything similar, and enjoy the relevant server/client code generation, documentation generation etc.? Can you point to relevant examples/resources?
OAS (formerly Swagger) considered it:
https://github.com/OAI/OpenAPI-Specification/issues/716
https://github.com/OAI/OpenAPI-Specification/issues/737
and even merged the callback feature and landed in OAS 3.0.
But the tools I used doesn't seems to support the addition at the moment.
Checkout out Async API
Quoting from https://www.asyncapi.com/v1/guide/
AsyncAPI provides a specification that allows you to define Message-Driven APIs in a machine-readable format. It’s protocol-agnostic, so you can use it for APIs that work over MQTT, AMQP, WebSockets, STOMP, etc. The spec is very similar to OpenAPI/Swagger so, if you’re familiar with them, AsyncAPI should be easy for you.
Repo: https://github.com/asyncapi/asyncapi
Async API supports
Documentation Generation : https://www.asyncapi.com/v1/tooling/docgens.html
Code Generation (Java, Node.js): https://www.asyncapi.com/v1/tooling/codegens.html
There is also Swagger Callback feature ( documentation for the callback feature. )
That comes with OAS 3.0 as far as I remember. So there isn't a tool which supports this feature yet.
I want to use AWS SQS in my Play 2.4 project.
There are two options at moment:
There is a SQS wrapper called https://github.com/kifi/franz which supports reactive way of using that. But it seems not quite popular on Github not sure how mature it is? Whether the developers will continue to maintain it.
There is Java SQS SDK, but it doesn't support Scala Future (reactive way). If I want to make it non-blocking, could I use Akka or?
I haven't used SQS yet but I did have a similar need for DynamoDB. I tried using a third party Scala specific library -- bad idea (buggy, bad api, missing features). In the end I wrapped the AWS Java SDK. Making it 'reactive' is pretty easy and is similar to most things you would do in Scala. Call the AWS functions within a Future body (Future {}) and use functional constructs to process the result (map, reduce etc..).
I am trying to build microservices with design first approach and using akka-http(scala) 2.4.1. For the design-first, IMHO, swagger is widely used. I couldn't find any boilerplate implementation as to how swagger works with akka-http.
How could I proceed?
I found a thread https://github.com/akka/akka/issues/16591 which talks about this to some extent, but couldn't find a conclusion / approach to take.
Also, there seems to be one not maintained version of a library https://github.com/Tecsisa/akka-http-swagger
In the swagger community, found a thread indicating to use swagger-inflector for ensuring the implementation is adhering to the swagger spec developed, but that seems to blend well with java and not with scala.
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