Mikhail Bazhenov2013-11-14 11:29:09
Mikhail Bazhenov, 2013-11-14 11:29:09

Agent infrastructure for building a web application

I want to build a web application. And choose an agent-based infrastructure as an infrastructure, for example, as http://habrahabr.ru/post/200906/

But as backend agents I want to use not node.js, but Java Spring MVC. And use node.js as a router between API agents and in order to quickly run into the cache. The organization of messaging over the http protocol in json format will be.

Yes, different languages ​​​​in the layers of routing and backend API are not good. But this gives greater code reliability than writing dolls on node.js.

Interested in your opinion and possible advice, I'm new to this architecture

Answer the question

In order to leave comments, you need to log in

1 answer(s)
Timur Shemsedinov, 2013-11-14

Here you are still afraid of the node, this is all because of the uncertainty in the new and unfamiliar technology. Do not be afraid and feel free to write both the API on the node, and the router on the node, and give the static to the node, and also subscribe clients to server events on the node. The homogeneity of technologies is worth understanding. I'm certainly not a Java expert, but it's absolutely not clear why you thought to use Java Spring MVC for backends. In essence, backends are APIs implemented either as RPC (stateful, stateful interaction on both ends) or REST (stateless, stateless interaction). What does MVC to API have to do with it? What the API should do is organize access to the database, process data, issue responses in the required format (let's say JSON), well, depending on whether RPC or REST - the API can either store state in memory or not store it, making individual requests independent, but depriving us of the ability to cache domain objects in memory within the session. On this occasion, I left a useful answer here -http://toster.ru/q/49346#answer_183494

Now about nesting dolls, in order to get away from them in writing API, the easiest way is to use async . The main problem is that you need to make several queries to the database and then, based on all the data fragments received asynchronously, execute business logic and generate a response.

var dataRequests = [];
// массив запросов к разным данным (БД, файлы, сетевые вызовы)
var dataResults  = {};
// я предпочитаю не использовать массив results, который дает async
// а вместо этого делать именованные фрагменты данных
// и писать их в свой хеш

// добавляем один запрос к данным
dataRequests.push(function(callback) {
    'SELECT * FROM TableName1 where Field1=?', [someValue1],
    function(err, res) {
      dataResults.firstPiceName = res;
      callback(err, null);

// добавляем второй запрос к данным
dataRequests.push(function(callback) {
    'SELECT count(*) FROM TableName2 where Field2=?',
    function(err, res) {
      dataResults.secondPiceName = res;
      callback(err, null);

// вызываем массив запросов асинхронно
async.series(dataRequests, function(err, results) {
  // тут делаем бизнес-логику над dataResults в котором у нас есть
  // все фрагменты данных .firstPiceName и .secondPiceName
  // и формируем общий результат

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question