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!
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.
We plan to use Vert.x framework for setting up our microservice, but at the same time we need to embed a third party application inside our microservice. This third-party application is multi-threaded, and thus I am not sure if this can be safely embedded inside our Vert.x based microservice. Can someone suggest reliable ways to proceed on this.
PS: I am very new to Vert.x so pardon me for my ignorance of it's internals, but I do understand Vert.x doesn't recommend multi-threading and goes with the Verticles based approach.
I know it is a subjective question, but the reason I ask this question is because
Node.js is not good with heavy computational task
Node.js has some issue with memory leak.
By having the problems above, would node be a good use case to build a payment gateway software?
I'm very comfortable with node, but there are many people said that its better to use other language like golang or scala for this type of systems.
Let me know what you guys think about, whether I should use Node or other languages.
Yes, node.js would be perfectly fine for payment gateway software. An appropriate design using clustering or off-loading computation tasks to child processes could easily help optimize heavy computational tasks.
And, node.js is being used by many heavy traffic commercial sites without memory leak issues. Memory leaks are an issue with faulty software design, not with the platform.
Further, the very nature of payment gateway software (being the middleman in a transaction between two other networking endpoints) is very well set up for the node.js async design that handles lots of in-flight transactions very efficiently.
As with pretty much any major back-end system these days, you just have to design your app to work the way the platform performs best and you could probably use any of the systems you mention just fine.
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.
Just to confirm if multithreading is supported in iPad and iPhone. I need to write an application that calls a web service on a background thread while user can still interact with the UI.
Yes, it has threads.
Also, you don't need to spawn your own threads for most tasks. A lot of the Apple Frameworks (Cocoa Touch Foundation frameworks) have built-in code that will do this for you.
Also, if you're consuming data from a Web API (HTTP Request), I highly recommend you take a look at ASIHTTPRequest, which is built on top of NSOperation (an operation class that easily handles background processing).
Finally, if you need help on program design/flow using the Model-View-Controller pattern, I've written a blog entry describing how to consume Web API data and present it to the end-user in a table format.
iOS has always supported multi-threading, just as Mac OS X did before it. Here's Apple's excellent overview documentation on the subject:
Concurrency Programming Guide