I heard some facts about ZeroMQ, and I think it's very powerful thing. But now I try to imagine how it can be applied in web application.
Could you make an example of using ZeroMQ in web applications?
So, the first that strikes me - simple chat application. So, we need frontend and backend. I prefer using python+Tornado as backend. There is python lib for using ZeroMQ. It's clear. So, the next thing is frontend. In frontend I will use some javascript to interact with backend.
So, to do this I should use ajax calls, right? Are there some other ways to do it?
TIA!
The easiest way to do this is to map WebSockets to ZeroMQ sockets, which is quite simple with tornado and PyZMQ's ZMQStream objects. An example of such an app is the IPython Notebook. This approach has the downside of requiring websockets, which puts a limit on what browsers you can support. Of course, you could also map ajax calls with jQuery, etc. and handle the relay with async handlers in tornado.
A more sophisticated web:ZeroMQ app is the mongrel2 webserver.
The right choice for you is just going to depend on your communication patterns.
Related
I will soon be starting a new project which involves upgrading my existing application frontend to use React.js. The current frontend makes standard REST calls to a server built using Microsoft technologies, which is not planning on changing any time soon.
I want to utilise the concept of server-side rendering and the new React Saga framework to improve SEO and performance. As I understand, in order to achieve this, I would need to run a Node.js server to enable this behaviour and make server-to-server calls from Node.js to the existing API.
My question is.. is this a common architecture? I.e having Node.js act as a middleman server? (UI - Node - Existing API). Or is there a better way/technique of integrating exiting non-JS APIs with the latest and greatest UI frameworks?
Any resources/materials you can provide for some reading on this topic would be a great help too!
Thanks.
Yes, its common and its also not bad, to split it that way:
Frontend Server
API(s)
The FE-Server will render and serve the UI.
The API(s) could be further splitted in many smaller microservices.
currently I'm working on this project (https://github.com/Giegling/addressbook) and for the backend I use Node.js with Express framework, for the frontend Angularjs. Is it possible to "translate" the backend to Haskell without touching the frontend? If it's possible, which framework should I use? (Yesod, scotty...)
Thanks
Your server simply exposes a HTTP API to your angular app. You can implement that functionality in any web framework (or even without a framework) in pretty much any language.
Yesod is probably the most popular and well documented Haskell framework (personal opinion), so I guess you can start with that.
I am a beginner to web development - I am building a website that requires some entries from the user, does some complicated mathematical processing on those entries, and returns the result to the client. I was thinking of implementing the mathematical stuff in another separate application which is better suited for such work (like in Java or C++ where there are good math libraries and the implementation would be more robust and faster). I was wondering what is the best way to do this, architecture-wise.
The "dummy" approach would be spawning a process from the Node.js application and waiting on its output from stdout, parsing it (probably in JSON) and then processing it before sending the result to the client. I have trouble believing that this is the best way to do this (it seems too error-prone, no proper error handling, dependent on the output, and just plain bad practice). A slightly better approach would be to have the Java or C++ application listening on a specific port and waiting for requests from the Node.js application. However this requires more thinking in terms of load-balancing (how would it scale with the number of requests?). Finally, the last approach I found online was to use a queuing system such as RabbitMQ as a way to communicate between the Node.js application and the Java application.
Typically (in a "traditional" software), implementing a separate library that holds all the math magic to which we can make calls would be a good way to go.
What is the best approach to achieve this with a Node.js/web application? There must be good practices/models/architectures/designs for such a problem. Thanks!
The best approach I can think of is writing a native nodejs module, you can use C++ and any library you have to write the code and export some APIs to be called from node's javascript.
This also allows you to package your native application as a module for nodejs, which can then be distributed and compiled/installed with npm.
Here's the official tutorial from node's website.
It isn't the easiest approach, but certainly the more elegant and mantainable one.
IF your problem can be structured in a stateless way -- i.e. you send a request out with the data and the associated task, and then later receive the result as a response, I would probably create one angular app for the front end, and multiple node servers for the back end (IF you needed to handle many requests simultaneously).
As pointed out in the first answer below, you can put whatever parts of the problem that you want to into native code, BUT what might be much easier is to use sockets to connect to a server to do the computation, in any language, etc... In one project I use a socket.service to handle all the communication back and forth to the servers. (The angular-fullstack generator in the next paragraph has such a skeleton socket.service piece.)
In terms of the frontend in combination with a node backend, The Yeoman generator (http://yeoman.io/generators/) for creating MEAN stack applications, using MongoDB, Express, AngularJS, and Node - lets you quickly set up a project following best practices. And the angular-fullstack generator will give you a framework that is light years ahead in so many ways. You can use yeoman to generate a sample application frontend (angular, express) and backend (NodeJs, MongoDB) with support for sockets, etc...
This too is not very simple, but in the end, with a few months of work, you would have a structured problem and solution that you would never outgrow. When I first wanted to work into this space, that was the path I took. And in truth the front-end was/is the harder part and the backend, connected with sockets, http, or whatever has gotten to be much simpler. In terms of servers, AWS, or even just nginx on Linux through DigitalOcean or many others is inexpensive and flexible.
I hope this helps.
I am working on app where I need to pass messages between a C++ application and a Javascript web app.
Certainly I could write sockets code myself in either language and I have done this in the past when necessary.
What I would really like is a higher-level message posting or message queueing API that does a lot of the work for me. Does anyone know of such an API?
I have looked at ICE, and it doesn't appear to have Javascript bindings. I have also looked at Boost message queue, but it only caters for the C++ side of things. If necessary I might roll my own Javascript bindings for either of these technologies.
UPDATE: Sorry should have mentioned this before, I want to run this in a browser.
To give a more complete story what I want is a simple browser-based app that is used to configure and display logging for a C++ application.
I know there are other ways of doing this, but I am specifically interested in a high-level library in both C++ and browser-based Javascript that builds a message queue ontop of the sockets API (if there isn't one then I might consider implementing it myself and writing up a code project article).
ALSO: I'm not bothered about portability in terms of the web browser. Eg if there is a high-level IPC Javascript library that only works in Chrome, I'll be happy with that.
With JavaScript I assume that you are running it in a browser? In this case your C++ application needs to provide a webserver and some kind of JSON based webservice that you can call. On the JavaScript side you just use AJAX to communicate with that webservice.
An alternative would be websockets which might be a little harder to implement on the C++ side though.
To simply answer your question: No, there is no IPC implemented in ECMAscript out of the box.
But you actually answered you question already. If you try to communicate with Javascript that runs in a browser, you indeed should use (web-)sockets connections to pipe date in either direction. Of course you could write a simple HTTP server in C++, but I guess that is overkill and does not have the capabilitys of bi-directional sockets.
It's still some work to implement a web-socket connection in C++ from the scratch (the specs were in flux for a long time), but I guess there are some librarys out already.
If you're trying to communicate with node.js, this is an almost trivial task using real sockets/pipes.
I have found a solution that meets my needs. It isn't exactly perfect but I think it works well enough.
Some people suggested using HTTP and ajax. That turned out to be a useful idea and after some prototyping I think it solves my rather basic needs.
To be more specific I am using the Mongoose HTTP server embedded in my C++ application and I am using the jQuery ajax function to pull data from the server. The jQuery client polls the server continously for new data, not particularly efficient but I think it will do the job good enough for me.
Once my implementation is complete I'll write an article explaining how to do this in detail and then I'll update this answer.
You could try DBus, it has very simple mechanism to define, query and use interfaces, and there are some components for XPCOM and webkit based browsers (for example http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge and http://code.google.com/p/v8-dbus/). Also DBus is opensource and cross platform.
For a server side or non-browser implementation how about named pipes?
Yes it's vintage technology and the usage depends which OS you use, but as long as your server side js environment has ability to read and write files it may work, and it fits the description 'high-level' inter-process communication.
I've been working with web2py recently, and found it very nice to use for building RESTful web apps. However I've decided to extend my JavaScript skills a bit and tackle a more 'modern', rich, asynchronous client-side JS application. Something like Gmail, in the sense that it loads the UI up-front and then only talks to the server to keep the data in sync.
I'd like to use Dojo (used Dojo and jQuery in the past, and prefer Dojo for its structure) for the client-side stuff, but what should I use on the server side? What's the best way to get Dojo's data stores talking to a standard MySQL database? I sense that something like web2py, as simple as it is, would be overkill when it really just needs to handle AJAX DB requests. I can imagine that if Dojo could talk directly to the DB a server-side framework might not be necessary at all.
There are a few questions like "what is the best framework", whether JS or server, but I guess I'm wondering what role the server-side framework plays at all in an app like Gmail, and what is the most suitable framework for such minimal logic processing?
When it comes to RIAs (Rich Internet Applications), the server needs to be just as robust and full featured as any other web application. The biggest difference is that the rendering of templates is outsourced to clients via javascript. So the short answer is, it doesn't matter. Just use whatever server side framework you feel most comfortable with.