I am developing a project and In this project I need calling multiple concurent web services ( least 5 webservice) asynchrously.
For that , whcih framework can be used Vertx , node , or Play
thanks
In play there is too much working out of the box. Node js will be nice if you can lose some time for writing your own tools.
All of these frameworks can be used.
Disclaimer: I work on the Play framework.
Given Play's Scala heritage, even if you're using Java, we provide Promises so that you can reason the flow of making async calls without suffering from what is known as "callback-hell". You may want to consider using promises for Node also... I believe they are available. I think Vert.x may offer something there too. I'm unsure but I don't believe Node and vert.x provide promises out of the box.
You may find this page useful: http://www.playframework.com/documentation/2.2.x/ScalaWS
Play documentation is not so good. If you are thinking to implement in scala play can be good option, but for java you may not find it so great as few things are not supported in Java (Eg to write a body parser of your own you need to use scala)
Nodejs can be a good choice however, in nodejs utilizing all the cpu cores is hard. There is a framework jxcore which claims to have a solution for this, but, I have not used it.
Vert.X IMO can be a good framework, it makes good use of all cpu cores, provides N event loops. Optionally, you can use worker thread pool if you really need to do cpu intensive operation and be responsive.
You can use vertx with RxJava module ( https://github.com/vert-x/mod-rxvertx ). You can combine your async results in anyway you want. rxvertx module supports wrappers for EventBus, HttpServer, HttpClient, NetServer, NetClient and Timer.
Related
Kotlin vs Node JS for REST Api's
I couldn't find any proper explanation regarding the differences b/w Kotlin and Node JS for REST APIs
Which is better in performance wise?
Let me set the context. Its Kotlin/JVM vs JS/Node.js. We cannot blindly say that this language is better. In general Kotlin is supposed to be faster since it compiled language compared to JS which is interpreted language.
Irrespective of the language used, we will discuss on the API architecture. Serving the APIs can be implemented in either blocking or non-blocking way (I am not going to explain about what it is). Traditionally before a few of years Java/Kotlin with Spring have been using the blocking architecture which delivered performance X. On a contrary, Node.js is based on non-blocking architecture which gave us better performance than the blocking architecture and architecture style is the only reason why Node.js performed better. Later Spring released a newer version of the framework to support non-blocking architecture. The non-blocking style is called as Reactive programming/Spring Webflux.
So now both of the languages support non-blocking architecture. In terms of raw language performance, Kotlin will be better since its compiled language. Also in theory interpreted languages are supposed to be slower. But we cannot say which is better without any testing.
Personally I am fan of Java/Spring because of OOPS and later at one point I started using TS/Node.js. TS eliminates most of the runtime issues with its type checking. But still we cannot compare it with the type system available in Java/Kotlin. As a language I feel Java/Kotlin is superior and one thing I like most in JavaScript is handling objects/JSON. Checkout "Kotlin for JavaScript" as well which lets you write in Kotlin and transpile to JS. Ignore this "Kotlin for JavaScript" feature, I am planning to try Kotlin/Spring in non-blocking architecture for my future projects. If you have usecases with WebSockets, I think Node.js will perform better and I am not sure If there are any libraries in Java/Kotlin since I havn't explored it.
One disadvantage in non-blocking style is that I need to pass the login context object to almost all the methods in the project. In blocking architecture we will add the login context information in thread local so that we can access it anywhere until the request is completed.
I am sure that I did not answer your question completely. But I hope that the information what I have give is useful.
Correct me If I am wrong in any of the aspects.
I want to be clear: I am asking about the case where I am not using any concurrency in my own implementation. I just want to know if the framework within which my backend will be invoked (ie google app engine) itself imposes thread-safety requirements on the code running on it.
Thank you!
P.S. as a related but separate question, is there any guidance on how to do multithreading in our own backend code (which then obviously needs to be appropriately thread-safe). Specifically, can we use java's standard executor services / thread pools, or there is some google-approved API? Thanks.
So google app engine or any other platform won't ensure thread safety for you because all the critical sections which your concurrency control techniques are trying to make thread safe are defined by the developer (you) and there is no way for the OS to know when reads and writes should occur. For the JVM, the two main concurrency libraries which are heavily used are the Guava libraries (made by google! ;-) ) and the Akka framework.
Both are great libraries, I've used both and have had a pleasure from their learning curves. I would also recommend looking into the Play Framework, they support the akka framework, and building reactive web apps is their main focus. If you're interested in learning some cool aspects of production frameworks, I would highly recommend learning and implementing Dropwizard (Google app engine doesn't support it, but the take aways you get from it definitely outweigh that con).
Please let me know if you have any questions!
Are there any javascript libraries for MPI? I am new to MPI and am learning about intensive parallel processing. We have a supercomputer at school that we are using that only uses MPI and I was wondering if I could code my programs using Node.js instead of c++.
Thanks.
A quick search on NPM doesn't reveal anything interesting, so my guess is that it does not exist yet.
However, you can use native libraries with http://nodejs.org/api/addons.html.
You can also use node-ffi, which sometimes makes things even simpler.
I know this answer is coming too in April 2019... But for future use and people interested in this topic:
Option 1: You can use Node.js Cluster API (https://nodejs.org/api/cluster.html) to mimic or implement simple MPI functions e.g. send, receive, rank, etc.. and much more advanced functions depending on your programming prowess in Node.js.
Option 2: You can also use the following Node.js' MPI library, which implements some of MPI functionalities. The library is available in NPM registry:
mpi-node - https://www.npmjs.com/package/mpi-node
I recently created klyng, a message-passing distributed computing framework for Node.js influenced by MPI. You can consider it (for now) a small implementation of the MPI Standards in javascript.
There seems to be one now. It seems to be becoming a popular standard in most languages.
Here's one web site:
https://www.npmjs.com/package/mpi-node
I have been reading about Clojure for some time and I'm considering it as a replacement to Node.js (which I have used for another project). The most promising library seems to be Aleph/Lamina, which unfortunately doesn't have nearly as many examples as Node. My questions are:
How can I process requests with a chain of async operations, such as reading a document from MongoDB, doing some calculations, saving the new document and sending it in the response? I was not able to write it from the examples in Lamina wiki page. It sounds like a pretty common use case and I was surprised not to found any code showing it. It would be great if you could show me some sample code.
Is this setup adequate for a heavy-load server (say, tens of thousands requests per second)? I can't afford to create one thread for each new request, so I need something similar to the Node approach.
Is there any example of a medium- or large-sized company out there using any of this?
Is there any better Clojure replacement to Node (besides Aleph/Lamina)? Perhaps Clojurescript targetting Node? My client is not written in Javascript, so using the same language in both client and server is not an advantage in my case.
Thanks!
Few pointers:
You need to look at Aleph which builds HTTP abstractions over Lamina channels abstraction.
Reading and writing docs to MongoDB can be async but the library should provide this. In Node.js the MongoDB library has to be async other wise it would screw up the Node programming model, where as this is not the case with Clojure so most probably the Clojure MongoDB library provides non-async function.
Async operations are only helpful in case of IO i.e reading/writing to mongodb, sending response back etc. Generation computations are CPU bound operations and has nothing to do with async model.
Vert.x is Java world Node.js. Clojure support is on roadmap. I would prefer Aleph as you can play in async and non-async world as required.
I am thinking of creating my own simple load test, where I can hit my website with multiple requests (like 100-1000 concurrent users) to see how it performs. I want to try Node.js out, but I don't know if it is the wrong technology for the job, since Node.js don't use threads?
Can I with the async model that Node.js uses, simulate the many user requests, or would that be more appropiate to do in another language like Ruby/.NET/Python?
Node.js ought to be perfect for the task. I do this at work. The one crucial piece that you will have to change is the http socket pool. The following code snipped will disable pooling entirely, letting you starve your Node.js process if you want to.
var http = require('http');
var req = http.request(..., agent: false)
You can read about this more at the http.Agent documentation.
Your concern about threads is astute, but even if you hit that limit (Node is very good at keeping your resources efficient) the solution is simple: start multiple instances (processes) of your load test. As it is, you may have to use multiple machines entirely to correctly simulate load.
In any case, you will not win automatically by using Ruby or Python for this. Asynchronous programming is ideal for I/O and network-bound tasks, and Node excels at this. Similarly, while Ruby and Python have third-party asynchronous frameworks, they're by definition more obscure than the standard asynchronous framework given in Node.
Node can fire off pretty much as many requests as you want it to (though you may have to change the defaults for http:Agent). You're more likely to be limited by what your OS can do than by anything inherent in node (and of course such limitations will apply in any other language you use).
It's simple to create load tests with nodeload.