Konstantin F | i am not a genius

Продолжение следует…

Я заметил, что мой блог таки читают. Это очень радует, что кому-то это приносит пользу. У меня просьба, напишите отзыв в поле для комментариев, на той странице, которая для вас оказалась полезна. Это помогло бы мне сделать блог лучше или удобней. Напишите, свое первое впечатление или мнение. В общем если понравилось пишите, если не понравилось, тем более пишите, будем исправлять.
Спасибо)

С Уважением
Konstantin F.

27. Чат через long-polling, чтение POST

Цель этой главы, научиться делать чат на Node.JS. Для начала, наш чат будет достаточно простой, всего лишь каждый кто заходить по этому url — localhost:3000 автоматически попадает в комнату, в которой получает сообщения. Например я набираю что то в одном окне браузера и то что я набрал появляется и в другом окне браузера, в данном случае оба браузера на одном компьютере но могут быть и на разных краях света.

Вот такой чат, просто обмен сообщениями. Мы будем делать его в начале без пользователей, без базы данных, без авторизации, такой вот простой, но качественно созданный чат. И так, поехали. Для начала как оно в общем будет устроено. Алгоритм общения с сервером, который изображен на этой схеме

Называется «long polling», что в переводе длинные запросы. Он с одной стороны очень простой, с другой стороны в девяносто процентах задач, когда нужно общаться с сервером, он отлично подходит. Посмотрим на него повнимательней. Когда клиент хочет получать данные от сервера, то он отправляет на сервер XMLHttpRequest, самый обычный запрос, но не обычной является его обработка сервером. Сервер, получив такой запрос, не будет сразу на него отвечать, а просто оставит запрос подвисшим, дальше в будущем, как только появятся данные для клиента, сервер ответит на этот запрос, клиент получит ответ, какое то сообщение, обработает его выведет сообщение и сделает новый запрос на сервер, сервер опять, если данных нет то подождет, подождет, как только данные появятся, тут же ответит. Фактически получается, что клиент все время старается держать рабочее соединение к серверу, по которому, как только данные будут готовы, он их сразу же получит. Соответствующий код на стороне клиента, выглядит так

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

<html>

<p class="lead">Добро пожаловать в чат!</p>

</form>

publish.onsubmit = function(){

var xhr = new XMLHttpRequest();

xhr.open("POST", "/publish", true)

xhr.send(JSON.stringify({message: this.elements.message.value}));

this.elements.message.value = '';

return false;

};

subscribe();

function subscribe(){

var xhr = new XMLHttpRequest();

xhr.open("GET", "/subscribe", true);

xhr.onload = function(){

var li = document.createElement('li');

li.textContent = this.responseText;

message.appendChild(li);

subscribe();

};

xhr.onerror = xhr.onabort = function(){

setTimeout(subscribe, 500);

};

xhr.send('');

}

</script>

</body>

</html>

Есть форма, для отправки сообщений

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

</form>

И есть список, «messages», куда сообщения приходят

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

При submit формы, создается XMLHttpRequest и сообщение обычным порядком постится на сервер

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

publish.onsubmit = function(){

var xhr = new XMLHttpRequest();

xhr.open("POST", "/publish", true)

xhr.send(JSON.stringify({message: this.elements.message.value}));

this.elements.message.value = '';

return false;

};

Ну а для получения новых сообщений, как раз используется алгоритм long polling описанный ранее. Есть функция subscribe()

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

function subscribe(){

var xhr = new XMLHttpRequest();

xhr.open("GET", "/subscribe", true);

xhr.onload = function(){

var li = document.createElement('li');

li.textContent = this.responseText;

message.appendChild(li);

subscribe();

};

xhr.onerror = xhr.onabort = function(){

setTimeout(subscribe, 500);

};

xhr.send('');

}

которая запускает XMLHttpRequest и говорит получи ка данные с этого url — xhr.open(«GET», «/subscribe», true); Когда будет получен ответ с сервера, он показывается в виде сообщения и заново вызывается функция subscribe();

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

xhr.onload = function(){

var li = document.createElement('li');

li.textContent = this.responseText;

message.appendChild(li);

subscribe();

};

то есть делается новый запрос. И так все это идет по кругу.

Исключение, если произошла ошибка или что то не так, в этом случае мы subscribe() тоже заново отправим, но с небольшой задержкой, чтобы не завалить сервер —

<html>
<body class="container">
<p class="lead">Добро пожаловать в чат!</p>

<form id="publish" class="form-inline">
    <input type="text" name="message"/>
    <input type="submit" class="btn btn-primary" value="Отправить"/>
</form>

<ul id="messages"></ul>

<script>

    publish.onsubmit = function(){
        var xhr = new XMLHttpRequest();

        xhr.open("POST", "/publish", true)

        xhr.send(JSON.stringify({message: this.elements.message.value}));

        this.elements.message.value = '';

        return false;
    };

    subscribe();

    function subscribe(){
        var xhr = new XMLHttpRequest();

        xhr.open("GET", "/subscribe", true);

        xhr.onload = function(){
            var li = document.createElement('li');
            li.textContent = this.responseText;
            message.appendChild(li);

            subscribe();
        };

        xhr.onerror = xhr.onabort = function(){
            setTimeout(subscribe, 500);
        };

        xhr.send('');
    }
</script>
</body>
</html>

xhr.onerror = xhr.onabort = function(){

setTimeout(subscribe, 500);

};

Обратим внимание, что этот код реализует алгоритм long polling, он не привязан к какому то конкретному чату, это просто код подписки на сообщение сервера, его можно расширять, можно добавлять различные каналы получения сообщений и так далее, но сейчас пока мы этого делать не будем, а перейдем к Node.JS.

Для серверной части у нас так же есть не большая заготовка

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    switch(req.url){
        case '/':
            sendFile("index.html", res);
            break;
        case '/subscribe':
            // ...
            break;
        case '/publish':
            // ...
            break;
        default:
            res.statusCode = 404;
            res.end("Not found");
    }
}).listen(3000);

function sendFile(fileName, res){
    var fileStream = fs.createReadStrem(fileName);
    fileStream
        .on('error', function(){
            res.statusCode = 500;
            res.end("Server error");
        })
        .pipe(res)
        .on('close', function(){
            fileStream.destroy();
        });
}

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

switch(req.url){

case '/':

sendFile("index.html", res);

break;

case '/subscribe':

// ...

break;

case '/publish':

// ...

break;

default:

res.statusCode = 404;

res.end("Not found");

}

}).listen(3000);

function sendFile(fileName, res){

var fileStream = fs.createReadStrem(fileName);

fileStream

.on('error', function(){

res.statusCode = 500;

res.end("Server error");

})

.pipe(res)

.on('close', function(){

fileStream.destroy();

});

}

которая представляет собой Http server, умеющий отдавать index.html в качестве главной страницы. Так же будут два url, вот такой — ‘/subscribe’, для подписки на сообщение, и такой — ‘/publish’, для отправки сообщений. Они в точности такие же, какие вы видели в index.html.

Начнем реализацию с подписки. Функция subscribe, со странички index.html, будет отправлять длинные запросы именно на url ‘/subscribe’. Клиент, который отправил запрос на subscribe, с одной стороны не должен получить ответ прямо сейчас, с другой стороны мы должны запомнить, что он обратился за данными, чтобы потом, когда данные появятся, ему их передать. Для решения этой задачи создадим специальный объект который будет называться «chat» и «chat.subscribe» будет запоминать что пришел клиент, для этого мы передадим ему объекты req и res — «chat.subscribe(req, res)». Ну а «chat.publish(«….»)» будет пересылать это сообщение всем клиентам которые сейчас есть. Описывать этот объект chat я буду в отдельном модуле который расположу в текущей директории.

26. Writable поток ответа res, метод pipe

Нашим следующим шагом будет использование потоков для работы с сетевыми соединениями и начнем мы с отдачи посетителю файлов. Если помните у нас была такая задача, если посетитель запросит соответствующий url, то отдать ему файл

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){
        
        fs.readFile('big.html', function(err, content){
            if(err){
                res.statusCode = 500;
                res.end("Server error");
            }else{
                res.setHeader("Content-Type", "text/html; charset=utf-8");
                res.end(content);
            }
        });
        
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

fs.readFile('big.html', function(err, content){

if(err){

res.statusCode = 500;

res.end("Server error");

}else{

res.setHeader("Content-Type", "text/html; charset=utf-8");

res.end(content);

}

});

}

}).listen(3000);

Пример решения этой задачи без потоков может быть таким

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){
        
        fs.readFile('big.html', function(err, content){
            if(err){
                res.statusCode = 500;
                res.end("Server error");
            }else{
                res.setHeader("Content-Type", "text/html; charset=utf-8");
                res.end(content);
            }
        });
        
    }
}).listen(3000);

fs.readFile('big.html', function(err, content){

if(err){

res.statusCode = 500;

res.end("Server error");

}else{

res.setHeader("Content-Type", "text/html; charset=utf-8");

res.end(content);

}

});

читаем файл, когда файл прочитается, вызываем callback. Дальше при ошибке сообщаем о ней,

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        fs.readFile('big.html', function(err, content){
            if(err){
                res.statusCode = 500;
                res.end("Server error");
            }else{
                res.setHeader("Content-Type", "text/html; charset=utf-8");
                res.end(content);
            }
        });

    }
}).listen(3000);

if(err){

res.statusCode = 500;

res.end("Server error");

а если все хорошо, то ставим заголовок, чтоб указать какой это файл

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        fs.readFile('big.html', function(err, content){
            if(err){
                res.statusCode = 500;
                res.end("Server error");
            }else{
                res.setHeader("Content-Type", "text/html; charset=utf-8");
                res.end(content);
            }
        });

    }
}).listen(3000);

}else{

res.setHeader("Content-Type", "text/html; charset=utf-8");

и записываем содержимое файла в ответ вызовом

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        fs.readFile('big.html', function(err, content){
            if(err){
                res.statusCode = 500;
                res.end("Server error");
            }else{
                res.setHeader("Content-Type", "text/html; charset=utf-8");
                res.end(content);
            }
        });

    }
}).listen(3000);

15	res.end(content);

который отдает content и завершает соединение.

Это решение в принципе работает, но его проблема, это пожирание памяти. Потому что, если файл большой, то readFile его сначала считает, а потом вызовет callback, в результате получится, что если клиент медленный, то весь этот считанный content зависнет в памяти до того пока клиент его получит. А что если у нас таких медленных клиентов много? А если файл очень большой? Получается, что сервер может почти мгновенно занять всю доступную память, что конечно же совершенно не приемлемо. Чтобы такого не происходило, мы заменим код отдачи файла на принципиально другой, использующий потоки.

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

}

}).listen(3000);

Мы уже умеем читать из файла используя ReadStream, это будет входным потоком данных, а выходным будет объект ответа «res», который является объектом класса ServerResponse наследующим от stream.Writable. Общий алгоритм использования потоков для записи сильно отличается от того, что мы рассматривали ранее и выглядит так

В начале мы создаем объект потока, если у нас http.Server, то этот объект уже создан, это res. Дальше мы хотим отправить что то клиенту, это можно сделать вызовом res.write и передать там наши данные, обычно это либо буфер, либо строка. Наши данные при этом добавляются к специальному свойству потока, которое называют его буфером. Если, пока, этот буфер не очень большой, то данные прибавляются к нему и write возвращает true, что означает, что мы можем писать еще, при этом обязательство по отсылке данных берет на себя поток, как правило эта отсылка происходит асинхронно. Возможен другой вариант, например если мы передали очень много данных или если буфер уже был чем то занят, то метод write() может вернуть false. False означает, что внутренний буфер потока переполнен и прямо сейчас запись конечно можно сделать, но это будет не целесообразно, потому что в буфере все будет просто копиться, копиться, копиться, по этому при получении false, обычно запись не продолжают, а ждут специального события «drain», которое будет сгенерировано потоком когда он все отошлет, то есть когда его внутренний буфер опустеет. Таким образом мы можем вызывать write много, много раз и когда мы понимаем, что всё, все данные записаны, то мы должны вызвать метод end(), тут тоже можем передать с первым аргументом данные — end([data]), в этом случае он просто write вызовет, самая главная задача end() это закончить запись. Поток это делает, при необходимости вызывает внутренние операции закрытия ресурсов, то есть файлов, соединений и так далее и затем генерирует событие finish, что означает, запись полностью завершена. Обращаю ваше внимание, что аналогичное событие у stream.Readable называется end(), это различие не случайно, потому что есть потоки дуплекс, которые умеют и читать и писать соответственно они могут генерировать как одно событие и другое.

Поток в любой момент можно разрушить вызовом метода destroy(), при вызове этого метода, работа потока прекращается и все ассоциированные с ним ресурсы будут освобождены. Конечно же событие «finish» уже никогда не состоится, потому что finish, это успешное окончание работы потока. Успешная отдача всех данных.

Реализуем успешную передачу всех данных используя эту схему

Я буду делать это в отдельной функции, которая будет называться sendFile(), она будет принимать один поток для файла и второй поток для ответа.

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read();
        res.write(filrContent);
    }
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.on('readable', write);

function write(){

var fileContent = file.read();

res.write(filrContent);

}

Первое, что мы будем делать с такой функцией это ждать данных, затем когда они получены, то внутри обработчика readable читать их и отправлять в ответ

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read();
        res.write(filrContent);
    }
}

function write(){

var fileContent = file.read();

res.write(filrContent);

}

Конечно же она не выдерживает ни какой критики, поскольку в том случае, если клиент пока не может получить эти данные, например потому что у него медленная скорость соединения, то они зависнут в буфере объекта res, таким образом, если файл очень быстро считан, но пока не отправлен, то он займет большое количество памяти, а этого мы как раз хотели бы избежать.

В этом небольшом коде изложен пример более универсального решения этой задачи

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read();
        if(fileContent && !res.write(fileContent)){
            file.removeListener('readable', write);

            res.once('drain', function(){
                file.on('readable',write);
                write();
            });
        }
    }
    
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.on('readable', write);

function write(){

var fileContent = file.read();

if(fileContent && !res.write(fileContent)){

file.removeListener('readable', write);

res.once('drain', function(){

file.on('readable',write);

write();

});

}

мы тоже читаем содержимое из файла на событии readable, но мы не просто отправляем его вызовом res.write(… ), а еще и анализируем, что этот вызов вернет. Если res принимает данные очень быстро, то res.write(…. ) будет возвращать true, это означает, что эта ветка if никогда не выполнится

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read();
        if(fileContent && !res.write(fileContent)){
            file.removeListener('readable', write);

            res.once('drain', function(){
                file.on('readable',write);
                write();
            });
        }
    }

}

if(fileContent && !res.write(fileContent)){

file.removeListener('readable', write);

res.once('drain', function(){

file.on('readable',write);

write();

});

}

соответственно мы получим read, write, read, write и так далее. Более интересный случай когда res.write(… ) вернул false, то есть когда буфер переполнен, в этом случае, мы временно отказываемся обрабатывать события readable на файле

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read();
        if(fileContent && !res.write(fileContent)){
            file.removeListener('readable', write);

            res.once('drain', function(){
                file.on('readable',write);
                write();
            });
        }
    }

}

21	file.removeListener('readable', write);

Само по себе, такое снятие обработчика не означает, что файловый поток перестанет читать данные, он будет читать данные, но он дочитает до определенного уровня, заполнит свой внутренний буфер объекта файл и затем, так как никто read не вызывает, то этот внутренний буфер останется заполненным на определенном уровне. То есть файловый поток что то считает и там застопорится, далее мы дождемся событие ‘drain’, то есть когда данные будут успешно отданы в ответ и когда данные отданы в ответ, это означает, что мы можем принять что то еще из файла, мы вновь показываем свой интерес в событиях ‘readable’ и вызываем метод write() сразу. Сразу, потому что пока мы ждали события ‘drain’ новые данные могли прийти, это означает, что имеет смысл их тут же прочитать, вызов read() вернет null если данных нет, ну а если есть, то они просто будут обработаны, тем же способом, о котором мы говорили раньше.

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read(); // Считать
        
        if(fileContent && !res.write(fileContent)){ // Отправить
            
            file.removeListener('readable', write);

            res.once('drain', function(){ // Подождать
                file.on('readable',write);
                write();
            });
        }
    }

}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.on('readable', write);

function write(){

var fileContent = file.read(); // Считать

if(fileContent && !res.write(fileContent)){ // Отправить

file.removeListener('readable', write);

res.once('drain', function(){ // Подождать

file.on('readable',write);

write();

});

}

Такая вот своеобразная рекурсивная функция получается — считать, отправить то что считано, при необходимости подождать ‘drain’, считать дальше, отправить, подождать и так далее по циклу, пока файл не закончится. По окончанию файла наступит событие ‘end’ в обработчике которого мы завершим ответ, вызовом res.end(), таким образом будет закрыто исходящее соединение, потому что файл полностью отослан.

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.on('readable', write);

    function write(){
        var fileContent = file.read(); // Считать

        if(fileContent && !res.write(fileContent)){ // Отправить

            file.removeListener('readable', write);

            res.once('drain', function(){ // Подождать
                file.on('readable',write);
                write();
            });
        }
    }
    file.on('end', function(){
        res.end();
    });
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.on('readable', write);

function write(){

var fileContent = file.read(); // Считать

if(fileContent && !res.write(fileContent)){ // Отправить

file.removeListener('readable', write);

res.once('drain', function(){ // Подождать

file.on('readable',write);

write();

});

}

file.on('end', function(){

res.end();

});

}

Получившийся код является весьма универсальным, он реализует достаточно общий алгоритм отправки данных из одного потока в другой, используя самые стандартные методы потоков readable и writable. Об этом конечно же подумали и разработчики самого Node.JS и добавили его несколько более оптимизированную реализацию в стандартную библиотеку потоков. Соответствующий метод называется pipe(), он есть у всех readable потоков и работает так —

Кроме того, что это всего лишь одна строка тут есть еще один бонус, например можно один и тот же входной поток «пайпить» в несколько выходных, например кроме ответа клиенту, будем выводить его еще в стандартный вывод процесса. Давайте запустим такой код

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.pipe(res);
    file.pipe(process.stdout);
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.pipe(res);

file.pipe(process.stdout);

}

Вывелось и клиенту в браузер и в консоль нашей IDE. Готов ли этот замечательный код к промышленной эксплуатации? Есть ли еще какие то нюансы которые нужно учесть? Первым делом в глаза должна бросится работа с ошибками, если вдруг файл не найден или что то с ним не так, тогда упадет весь сервер вообще. Это не то что нам нужно, поэтому добавим обработчик, получаем это

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.pipe(res);

    file.on('error', function(err){
        res.statusCode = 500;
        res.end("Server Error");
        console.error(err);
    });
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.pipe(res);

file.on('error', function(err){

res.statusCode = 500;

res.end("Server Error");

console.error(err);

});

}

Что же, мы теперь немножко ближе к реальной жизни и в ряде руководств такой код выдается за вполне нормальный, но на самом деле это не так, ставить такой код на живой сервер ни в коем случае нельзя. В чем же дело? для того чтобы продемонстрировать проблему я сейчас добавлю дополнительные обработчики на события open и close для файла.

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.pipe(res);

    file.on('error', function(err){
        res.statusCode = 500;
        res.end("Server Error");
        console.error(err);
    });

    file
        .on('open', function(){
            console.log("open");
        })
        .on('close', function(){
            console.log("close");
        });
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.pipe(res);

file.on('error', function(err){

res.statusCode = 500;

res.end("Server Error");

console.error(err);

});

file

.on('open', function(){

console.log("open");

})

.on('close', function(){

console.log("close");

});

}

стартую и обновляю в браузере страницу, обновляю, обновляю несколько раз

Видите файл перезагружается и совершенно нормально, то что файл открывается, потом он целиком отдается и закрывается. Теперь я открою консоль и запущу утилиту curl которая будет скачивать вот этот url — http://localhost:3000/big.html с ограничением скорости в один килобайт в секунду.

Давайте поставим эту утилиту. Для этого ищем в гугле curl

раз википедия, так википедия, там находим официальный сайт — https://curl.haxx.se/ и на нем во вкладке download в низу списка находим нашу винду и качаем архив

Распаковав архив в корень диска С: в директорию curl мы сначала устанавливаем сертификат безопасности кликнув по нему дважды, а потом прописываем в глобальную переменную path путь ко второму файлу в этой папке, к curl.exe, это нужно, чтоб я мог обращаться к этой утилите из консоли, то есть дописываем в path путь к папке, в которой находится наша утилита.

Продолжим, напомню у нас запущен сервер pipe.js и следим за консолью IDE, открыли окно команд в Windows, и вводим следующую команду

C:\Users\ASUS\Desktop>curl --limit-rate 1k http://localhost:3000/big.html

1	C:\Users\ASUS\Desktop>curl --limit-rate 1k http://localhost:3000/big.html

Запустили, и открывается файл начинается получение, с виду все хорошо, но если нажать Ctrl+C, то есть прекратить загрузку, мы не увидим в консоле нашей IDE ни какого close

видите, я трижды начинал загрузку и прерывал, ни одного закрытия. Для того чтоб повторить эксперимент файл должен быть более 3Mb. Иначе говоря, если клиент открыл соединение, но закрыл его до того как загрузка файла была завершена, то получается что файл останется подвисшим. А если файл остался открытым, то во первых все ассоциированные с ним структуры остались тоже в памяти, во вторых в операционных системах зачастую есть лимит на количество одновременно открытых файлов. А в третьих вместе с файлом навечно зависает в памяти и соответствующий объект потока, а вместе с ним и все замыкание в котором он находится. Чтобы избежать этой проблемы и следствий, достаточно всего лишь отловить момент, когда соединение закрыто и при этом удостовериться, что файл тоже будет закрыт. Событие которое нас интересует, называется res.on(‘close’, ….) и это событие отсутствует в обычном Stream.writable, то есть это именно расширение стандартного интерфейса потоков, так же как у файла есть close — file.on(‘close’, …), так и у объекта ответа server response тоже есть close — res.on(‘close’, ….). Но смысл последнего сильно отличается от первого, это очень важно, потому что на файловом потоке ‘close’ это нормальное завершение, файл закрывается всегда в конце, а для объекта ответа, ‘close’ это сигнал о том, что соединение было оборвано, при нормально завершении происходит не ‘close’, а ‘finish’. Итак, если соединение было оборвано, то нам нужно закрыть файл и освободить все ресурсы, поскольку файл нам больше передавать некому, для этого мы вызываем метод потока file.destroy(); теперь все будет хорошо. Теперь давайте еще раз проверим

var http = require('http');
var fs = require('fs');

new http.Server(function(req, res){
    // res instanceof http.ServerResponse < stream.Writable

    if(req.url == '/big.html'){

        var file = new fs.ReadStream('big.html');
        sendFile(file, res);

    }
}).listen(3000);

function sendFile(file, res){
    file.pipe(res);

    file.on('error', function(err){
        res.statusCode = 500;
        res.end("Server Error");
        console.error(err);
    });

    file
        .on('open', function(){
            console.log("open");
        })
        .on('close', function(){
            console.log("close");
        });

    res.on('close', function(){
        file.destroy();
    });
}

var http = require('http');

var fs = require('fs');

new http.Server(function(req, res){

// res instanceof http.ServerResponse < stream.Writable

if(req.url == '/big.html'){

var file = new fs.ReadStream('big.html');

sendFile(file, res);

}

}).listen(3000);

function sendFile(file, res){

file.pipe(res);

file.on('error', function(err){

res.statusCode = 500;

res.end("Server Error");

console.error(err);

});

file

.on('open', function(){

console.log("open");

})

.on('close', function(){

console.log("close");

});

res.on('close', function(){

file.destroy();

});

}

Теперь наш код можно пускать на живой сервер.

25. Потоки данных в Node.JS, fs.ReadStream

Тема этой главы, потоки в Node.JS. Мы постараемся разобраться в этой теме хорошо и подробно, по сколько, с одной стороны , так получается, что потоки в обычной браузерной JavaScript разработке отсутствуют, а с другой стороны, уверенное владение потоками необходимо для грамотной серверной разработке, по скольку поток, является универсальным способом работы с источниками данных, которые используются повсеместно.

Можно выделить два основных типа потоков.

Первый поток — stream.Readable — чтение.
stream.Readable это встроенный класс, который реализует потоки для чтения, как правило сам он не используется, а используются его наследники. В частности для чтения из файла есть fs.ReadSream. Для чтения запроса посетителя, server.on(‘request’, …req…), при его обработки, есть специальный объект, который мы раньше видели под именем req, первый аргумент обработчика запроса.

Второй поток — stream.Writable — запись.
stream.Writable это универсальный способ записи и здесь тоже, сам stream.Writable обычно не используется, но используются его наследники.
…в файл: fs.WriteStream
…в ответ посетителю: server.on(‘request’, …res…)

Есть и некоторые другие типы потоков, но наиболее востребованные это предыдущие два и производные от них.

Самый лучший способ разобраться с потоками это посмотреть как они работают на практике. Поэтому сейчас мы начнем с того, что используем fs.ReadStream для чтения файла.

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream(__filename);

stream.on('readable', function(){
    var data = stream.read();
    console.log(data);
});

stream.on('end', function(){
    console.log("THE END");
});

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable

var stream = new fs.ReadStream(__filename);

stream.on('readable', function(){

var data = stream.read();

console.log(data);

});

stream.on('end', function(){

console.log("THE END");

});

Итак, здесь я подключаю модуль fs и создаю поток. Поток это JavaScript объект, который получает информацию о ресурсе, в данном случае путь к файлу — «__filename» и который умеет с этим ресурсом работать. fs.ReadStream реализует стандартный интерфейс чтения который описан в классе stream.Readable. Посмотрим его на схеме

Когда создается объект потока — «new stream.Readable», он подключается к источнику данных, в нашем случае это файл, и пытается начать из него читать. Когда он что то прочитал, то он эмитирует событие — «readable», это событие означает, что данные просчитаны и находятся во внутреннем буфере потока, который мы можем получить используя вызов «read()». Затем мы можем что то сделать с данными — «data» и подождать следующего «readable» и снова если придется, и так дальше. Когда источник данных иссяк, бывают конечно источники которые не иссякают, например датчики случайных чисел, но размер файла то ограничен, поэтому в конце будет событие «end», которое означает, что данных больше не будет. Так же, на любом этапе работы с потоком, я могу вызвать метод «destroy()» потока. Этот метод означает, что мы больше не нуждаемся в потоке и можно его закрыть, и закрыть соответствующие источники данных, полностью все очистить.

А теперь вернемся к исходному коду. Итак здесь мы создаем ReadStream

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream(__filename);

stream.on('readable', function(){
    var data = stream.read();
    console.log(data);
});

stream.on('end', function(){
    console.log("THE END");
});

//fs.ReadStream наследует от stream.Readable

var stream = new fs.ReadStream(__filename);

и он тут же хочет открыть файл. Но тут же, в данном случае вовсе не означает на этой же строке, потому что как мы помним, все операции с вводом выводом, реализуются через «LibUV», а «LibUV» устроено так, что все синхронные обработчики ввода вывода сработают на следующей итерации событийного цикла, то есть заведомо после того, как весь текущий JavaScript закончит работу. Это означает, что я могу без проблем навесить все обработчики и я твердо знаю что они будут установлены до того как будет считан первый фрагмент данных. Запускаю этот код и смотрим, что вывелось в консоле

Первое сработало событие ‘readable’ и оно вывело данные, сейчас это обычный буфер, но я могу преобразовать его к строке используя кодировку utf-8 обычным вызовом toString

Еще один вариант, указать кодировку непосредственно при открытии потока

тогда преобразование будет автоматическим и toString() нам не нужен.

Наконец когда файл закончился,

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream(__filename, {encoding: 'utf-8'});

stream.on('readable', function(){
    var data = stream.read();
    console.log(data);
});

stream.on('end', function(){
    console.log("THE END");
});

stream.on('end', function(){

console.log("THE END");

});

то событие ‘end’ вывело мне в консоль «THE END». Здесь фай закончился почти сразу, поскольку он был очень маленький. Сейчас я не много модифицирую пример, сделаю вместо «__filename», то есть вместо текущего файла, файл «big.html», который в текущей директории находится.

Файл big.html большой, по этому событие readable срабатывало многократно и каждый раз мы получали очередной фрагмент данных в виде буфера. Так же обратите внимание на вывод null который нас постоянно преследует, о причине этого вывода вы можете прочесть в документации, там сказано, что после того как данные заканчиваются readable возвращает null. Возвращаясь к нашему буферу, давайте я выведу в консоль его размер и заодно сделаю проверку на но то чтоб вывод был не null

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream("big.html");

stream.on('readable', function(){
    var data = stream.read();
    if(data != null)console.log(data.length);
});

stream.on('end', function(){
    console.log("THE END");
});

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable

var stream = new fs.ReadStream("big.html");

stream.on('readable', function(){

var data = stream.read();

if(data != null)console.log(data.length);

});

stream.on('end', function(){

console.log("THE END");

});

Эти числа, не что иное как длина прочитанного фрагмента файла, потому что поток когда открывает файл, он читает из него не весь файл конечно же, а только кусок и помещает его в свою внутреннюю переменную и максимальный размер, это как раз шестьдесят четыре килобайта. Пока мы не вызовем stream.read(), он дальше читать не будет. После того как я получил очередные данные, то внутренний буфер очищается и он может еще фрагмент прочитать, и так далее и так далее, последний фрагмент имеет длину остатка данных. На этом примере мы отлично видим важное преимущество использования потоков, они экономят память, какой бы большой файл не был, все равно, единовременно мы обрабатываем вот такой небольшой фрагмент. Второе, менее очевидное преимущество, это универсальность интерфейса. Здесь

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream("big.html");

stream.on('readable', function(){
    var data = stream.read();
    if(data != null)console.log(data.length);
});

stream.on('end', function(){
    console.log("THE END");
});

4	var stream = new fs.ReadStream("big.html");

мы используем поток ReadStream из файла, но мы можем в любой момент заменить его на вообще произвольный поток из нашего ресурса, это не потребует изменения оставшейся части кода

var fs = require('fs');

var stream = new OurStream("our resourse");

stream.on('readable', function(){
    var data = stream.read();
    if(data != null)console.log(data.length);
});

stream.on('end', function(){
    console.log("THE END");
});

var fs = require('fs');

var stream = new OurStream("our resourse");

stream.on('readable', function(){

var data = stream.read();

if(data != null)console.log(data.length);

});

stream.on('end', function(){

console.log("THE END");

});

Потому что потоки это в первую очередь интерфейс, то есть в теории, если наш поток реализует необходимые события и методы, в частности наследует от stream.Readable, то все должно работать хорошо, но это конечно же только в том случае если мы не использовали специальных возможностей, которые есть у файловых потоков. В частности у потока ReadStream есть дополнительные события

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream("big.html");

stream.on('readable', function(){
    var data = stream.read();
    if(data != null)console.log(data.length);
});

stream.on('end', function(){
    console.log("THE END");
});

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable

var stream = new fs.ReadStream("big.html");

stream.on('readable', function(){

var data = stream.read();

if(data != null)console.log(data.length);

});

stream.on('end', function(){

console.log("THE END");

});

Здесь изображена схема именно для fs.ReadStram и новые события изображены красным

Вначале это открытие файла, а в конце закрытие. Обратим внимание, что если файл полностью дочитан, то возникает событие «end» затем «close», а если файл не дочитан, например из за ошибки или при вызове метода destroy(), то «end» не будет, поскольку файл не закончился, но всегда гарантируется, при закрытии файла, событие «close».

И наконец, последняя по коду, но не последняя по важности деталь, обработка ошибок. Например посмотрим что будет если файла нет

упс, все упало. Обратите внимание, потоки наследуют от event EventEmitter, про него была глава, если происходит ошибка, то весь процесс node.js падает. Это в том случае конечно, если на эту ошибку нет обработчиков, по этому если мы хотим, чтоб Node.JS вообще не упал, то нужно обязательно обработчик поставить

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable
var stream = new fs.ReadStream("none.html");

stream.on('readable', function(){
    var data = stream.read();
    if(data != null)console.log(data.length);
});

stream.on('end', function(){
    console.log("THE END");
});

stream.on('error', function(err){
    if(err.code == 'ENOENT'){
        console.log("Файл не найден");
    }else{
        console.error(err);
    }
});

var fs = require('fs');

//fs.ReadStream наследует от stream.Readable

var stream = new fs.ReadStream("none.html");

stream.on('readable', function(){

var data = stream.read();

if(data != null)console.log(data.length);

});

stream.on('end', function(){

console.log("THE END");

});

stream.on('error', function(err){

if(err.code == 'ENOENT'){

console.log("Файл не найден");

}else{

console.error(err);

}

});

Итак, для работы с источниками данных в Node.JS используются потоки, здесь мы рассмотрели общую схему по которой они работают

и ее конкретную реализацию, а именно fs.ReadStrem

которая умеет читать из файла.

24. Безопасный путь к файлу в fs и path

В этой главе мы рассмотрим, как при помощи Node.JS создать веб сервер, который будет возвращать файл юзеру из директории public. Может возникнуть вопрос, зачем здесь Node.JS? Почему бы не сделать это на другом сервере, например Nginx. Вопрос совершенно уместен, да для отдачи файлов, как правило, другие сервера будут более эффективны. С Другой стороны node, во первых, работает тоже весьма неплохо, а во вторых, может, перед отдачей файла, совершить какие то интеллектуальные действия. Например обратится к базе данных, проверить имеет ли юзер право на доступ к файлам, и только если имеет, тогда уже отдавать.

Итак начинаем.

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;
        
        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

var http = require('http');

var fs = require('fs');

var url = require('url');

var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

if(!checkAccess(req)){

res.statusCode = 403;

res.end("Tell me the secret to access!");

return;

}

sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){

return url.parse(req.url, true).query.secret == 'o_O';

}

function sendFileSafe(filePath, res){

try{

filePath = decodeURIComponent(filePath);

}catch(e){

res.statusCode = 400;

res.end("Bad Request");

return;

}

if(~filePath.indexOf('\0')){

res.statusCode = 400;

res.end("Bad Request");

return;

}

filePath = path.normalize(path.join(ROOT, filePath));

if(filePath.indexOf(ROOT) != 0){

res.statusCode = 404;

res.end("File not found");

return;

}

fs.stat(filePath, function(err, stats){

if(err || !stats.isFile()){

res.statusCode = 404;

res.end("File not found");

return;

}

sendFile(filePath, res);

});

}

function sendFile(filePath, res){

fs.readFile(filePath, function(err, content){

if (err) throw err;

var mime = require('mime').lookup(filePath);

res.setHeader('Content-Type', mime + "; charset=utf-8");

res.end(content);

});

}

Вот такой у нас получился код, с массой проверок, сейчас мы его подробно разберем.

http.createServer(… ) здесь очень прост

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

http.createServer(function(req, res){

if(!checkAccess(req)){

res.statusCode = 403;

res.end("Tell me the secret to access!");

return;

}

sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

он будет проверять, есть ли доступ к данному файлу

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

if(!checkAccess(req)){

res.statusCode = 403;

res.end("Tell me the secret to access!");

return;

}

и если есть, отдавать

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

sendFileSafe(url.parse(req.url).pathname, res);

Для проверки доступа, мы будем использовать следующую, по сути заглушечную функцию,

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "/public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

function checkAccess(req){

return url.parse(req.url, true).query.secret == 'o_O';

}

которая будет парсить url и если есть параметр ‘secret’, который равен ‘o_O’, то считается, что доступ есть. В реальной жизни такая проверка будет производиться, конечно же при помощи cookie, базы данных и так далее. Основная функция, которая нас здесь интересует, это sendFileSafe(…. ). Именно эта функция должна, получив, в качестве первого параметра, путь от юзера — «url.parse(req.url).pathname» отослать соответствующие файлы из директории «public», учитывая поддиректории. И важнейший аспект, который в ней должен быть заложен, это безопасность. Какой бы путь не передал юзер, он ни в коем случае не должен получить файл вне этой директории. Например, вот такое обращение

должно возвращать файл index.html и картинка здесь взята из директории deep\nodejs.jpg

А если бы я не указал seceret=o_O, то оно должно было выдать мне ошибку с кодом 403

Ну а если я попробовал указать вот так вот

тоже ошибка. И так для любых попыток выйти за пределы директории.

Итак смотрим функцию sendFileSafe(filePath, res), чтобы получить пример безопасной работы с путем от посетителя.

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

function sendFileSafe(filePath, res){

try{

filePath = decodeURIComponent(filePath);

}catch(e){

res.statusCode = 400;

res.end("Bad Request");

return;

}

if(~filePath.indexOf('\0')){

res.statusCode = 400;

res.end("Bad Request");

return;

}

filePath = path.normalize(path.join(ROOT, filePath));

if(filePath.indexOf(ROOT) != 0){

res.statusCode = 404;

res.end("File not found");

return;

}

fs.stat(filePath, function(err, stats){

if(err || !stats.isFile()){

res.statusCode = 404;

res.end("File not found");

return;

}

sendFile(filePath, res);

});

}

Эта функция состоит из нескольких шагов. На первом шаге я пропускаю путь через decodeURIComponent(filePath),

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

try{

filePath = decodeURIComponent(filePath);

}catch(e){

ведь по стандарту http многие символы кодируются, в частности русская буква «я» будет иметь вот такой вид в url -«%D1%8F» и это корректно. Получив такой url мы обязаны его декодировать обратно в русскую букву «я» при помощи вызова decodeURIComponent(…. ), при этом если url закодирован неверно, то возникнет ошибка, которую необходимо поймать и обработать. В catch мы как раз указываем, resStatusCode = 400, что означает, что url некорректен, запрос неверен, можно конечно и просто вернуть res.statusCode = 404.

Далее когда мы раскодировали запрос, время его проверить

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

if(~filePath.indexOf('\0')){

res.statusCode = 400;

res.end("Bad Request");

return;

}

есть такой специальный нулевой байт, который, по идеи, в строке url присутствовать не должен. Если он есть, это означает, что кто то его злонамеренно передал, потому что некоторые встроенные функции Node.JS будут работать с таким байтом некорректно. Соответственно, если такой байт есть, то мы тоже возвращаем- до свидание, запрос некорректен.

Теперь настало получить полный путь к файлу на диске. Для этого мы будем использовать модуль path.

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

filePath = path.normalize(path.join(ROOT, filePath));

Этот модуль содержит пачку самых разных функций для работы с путями. Например join объединяет пути, normalize — удаляет из пути, всякие странные вещи типа «.» «..» «\\» и так далее, то есть делает путь более корректным. Если url который передал юзер выглядел так — «/deep/nodejs.jpg», то после join с ROOT, который представляет собой вот эту — «var ROOT = __dirname + «\\public»» директорию, он будет выглядеть уже по другому — «C:\node\server\public\deep\nodejs.jpg»

Наша следующая задача это убедится, что путь действительно находится внутри директории public. Сейчас, когда у нас уже есть абсолютно точный, корректный абсолютный путь, это сделать очень просто — достаточно всего лишь проверить, что в начале находится вот такой вот префикс — «C:\node\server\public\» то есть, что путь начинается с ROOT. Проверяем и если это не так, то до свидание файла нет

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

if(filePath.indexOf(ROOT) != 0){

res.statusCode = 404;

res.end("File not found");

return;

}

Далее, если путь разрешен, то проверим, что по нему лежит. Если ничего нет, то fs.stat вернет ошибку ну или если даже ошибки нет, то нужно проверить файл ли это

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

fs.stat(filePath, function(err, stats){

if(err || !stats.isFile()){

res.statusCode = 404;

res.end("File not found");

return;

}

В том случае если это не файл — ошибка, ну а если файл, то все проверено, там файл, надо его отослать. Это делает вложенный вызов sendFile(…. ).

sendFile(…. ), функция которая есть в этом же файле чуть чуть ниже.

var http = require('http');
var fs = require('fs');
var url = require('url');
var path = require('path');

var ROOT = __dirname + "\\public";

http.createServer(function(req, res){

    if(!checkAccess(req)){
        res.statusCode = 403;
        res.end("Tell me the secret to access!");
        return;
    }

    sendFileSafe(url.parse(req.url).pathname, res);

}).listen(3000);

function checkAccess(req){
    return url.parse(req.url, true).query.secret == 'o_O';
}

function sendFileSafe(filePath, res){
    try{
        filePath = decodeURIComponent(filePath);
    }catch(e){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    if(~filePath.indexOf('\0')){
        res.statusCode = 400;
        res.end("Bad Request");
        return;
    }

    filePath = path.normalize(path.join(ROOT, filePath));

    if(filePath.indexOf(ROOT) != 0){
        res.statusCode = 404;
        res.end("File not found");
        return;
    }

    fs.stat(filePath, function(err, stats){
        if(err || !stats.isFile()){
            res.statusCode = 404;
            res.end("File not found");
            return;
        }

        sendFile(filePath, res);
    });
}

function sendFile(filePath, res){
    fs.readFile(filePath, function(err, content){
        if (err) throw err;

        var mime = require('mime').lookup(filePath);
        res.setHeader('Content-Type', mime + "; charset=utf-8");
        res.end(content);
    });
}

function sendFile(filePath, res){

fs.readFile(filePath, function(err, content){

if (err) throw err;

var mime = require('mime').lookup(filePath);

res.setHeader('Content-Type', mime + "; charset=utf-8");

res.end(content);

});

}

Она для чтения файла использует вызов fs.readFile(…. ) и когда он будет прочитан, то выводит его через res.end(…). Обращаю ваше внимание вот на что, во первых ошибка в этом callback очень мало вероятна, хотя бы потому что мы уже проверили, что файл есть, это действительно файл, то есть его можно отдать, но тем не менее мало ли что, например может возникнуть ошибка при чтении с диска, так или иначе, как то обработать ошибку надо — «if (err) throw err» .

Далее, мало просто считать содержимое файла и отправить его, ведь различные файлы должны снабжаться различными заголовками contant-type — «res.setHeader(‘Content-Type’, mime + «; charset=utf-8″)». Например html файл должен иметь тип text/html, файл с картинкой jpg — image/jpg и так далее. Нужный тип файла определяется по расширению с использованием модуля «mime», для того чтоб это работало, нужно его поставить дополнительно «npm install mime», и затем вызвать.

Ну и на конец последнее: эта глава была сосредоточена на том, чтобы корректно работать с путем от посетителя, чтобы сделать все необходимые проверки, но что касается отдачи файла, этот код не верен, я про функцию sendFile(… ), потому что readFile полностью прочитывает файл и потом в content его отсылает. А представьте, что будет если файл очень большой, а если он превышает количество свободной памяти, вообще же все упадет. По этому для того чтобы отсылать файл нужно либо дать команду специализированному серверу, либо использовать потоки которые мы рассмотрим в следующих главах.

23. Работа с файлами, модуль fs

Цель этой главы, научить нас работать с бинарными данными и файловой системой. В Node.JS, для работы с файлами существует модуль «FS» и в нем есть множество функций для самых различных операций с файлами и директориями. Вот документация. Если мы приглядимся внимательно, то увидим первую особенность этого модуля, почти все функции имеют два варианта.

Первое просто имя, второе со словом Sync. Слово Sync означает синхронно.Если я например вызову fs.readFile(file[, options], callback), то он сначала прочитает файл полностью, а потом вызовет callback. А fs.readFileSync(file[, options]) затормозит выполнение процесса пока файл не будет прочитан. По этому, как правило синхронный вызов используют либо в консольных утилитах, либо на стадии инициализации сервера, когда такие тормоза допустимы. А асинхронный вызов, в тех случаях когда хочется, чтоб полноценно работал событийный цикл, то есть, чтоб Node.JS не ждал пока диск сработает, медленно и файл прочитается.

Посмотрим на реальный пример использования.

var fs = require('fs');

fs.readFile(__filename, function(err, data){
    if(err){
        console.error(err);
    }else{
        console.log(data);
    }
});

var fs = require('fs');

fs.readFile(__filename, function(err, data){

if(err){

console.error(err);

}else{

console.log(data);

}

});

Здесь я подключаю модуль «fs» и вызываю, асинхронно, функцию readFile(…). Эта функция принимает имя файла, в данном случае «__filename» это путь к текущему файлу модуля, и получает callback, первый аргумент, как всегда, ошибка, второй данные, то есть, содержимое файла. Если бы это был синхронный вызов, то это выглядело бы так

var fs = require('fs');

try{
    var data = fs.readFileSync(__filename);
}catch(e){
    console.error(err);
}

fs.readFile(__filename, function(err, data){
    if(err){
        console.error(err);
    }else{
        console.log(data);
    }
});

var fs = require('fs');

try{

var data = fs.readFileSync(__filename);

}catch(e){

console.error(err);

}

fs.readFile(__filename, function(err, data){

if(err){

console.error(err);

}else{

console.log(data);

}

});

При этом в случае ошибки было бы исключение. Но мы здесь дальше будем работать с асинхронными вызовами по этому я это удалю, а запущу наш

var fs = require('fs');

fs.readFile(__filename, function(err, data){
    if(err){
        console.error(err);
    }else{
        console.log(data);
    }
});

var fs = require('fs');

fs.readFile(__filename, function(err, data){

if(err){

console.error(err);

}else{

console.log(data);

}

});

и вот, что я получаю в качестве вывода.

Обратите внимание, вывелось не содержимое файла в виде строки, а специальный объект буфер. Этот объект буфер является высокоэффективным средством Node.JS для работы с бинарными данными. Технически буфер, это непрерывная область памяти, которая, в данном случае, заполнена этими данными. И работа с буфером достаточно похожа на работу со строкой. То есть можно взять, например, и получить нулевой элемент.

data[0];

data[0];

Можно взять и получить длину буфера

data.length

1	data.length

Но в отличии от строк, которые в JavaScript абсолютно неизменяемы, содержимое буфера можно менять. Для этого в документации предусмотрено ряд методов, от простейшего метода buf.write(string[, offset[, length]][, encoding]) , который пишет в буфер строку, преобразуя ее в бинарный формат, учитывая данную кодировку и заканчивая различными методами которые записывают в буфер целые числа, дробные числа, числа в формате double и другие числа, учитывая внутреннее, компьютерное, двоичное представление данных форматов

В данном случае, мы бы хотели вывести содержимое файла в виде строки. По этому давайте преобразуем буфер в строку, это можно делать вызовом toString и в скобках указать кодировку, то есть таблицу, которая указывает как преобразовать байты в символы алфавита. Обычно кодировка по умолчанию — это ‘utf-8’. Если хотим так и оставить, то можно не указывать. Запускаем

Ну вот, теперь строка.

Если точно знаю, что я работаю со строками, то я могу указать кодировку прямо здесь, это будет выглядеть так

В этом случае, преобразование в строку происходит непосредственно внутри функции fs.readFile(…. ).

Ну хорошо, а теперь давайте посмотрим, что происходит если где то ошибка. Например, я считываю файл которого не существует

О! Вывелась ошибка в консоль Error. Обращаю ваше внимание, что в ошибке есть следующие данные:

Во первых, имя ошибки — code: ‘ENOENT’, в данном случае означает, что файла нет.
Во вторых это код цифровой — errno: -4058, и оба кода являются полностью кроссплатформенными, то есть не важно, под Windows, под Linux, еще под чем то я нахожусь, всегда если файл не найден, то это означает ошибка ‘ENOENT’. Соответственно мы можем проверить если код такой

var fs = require('fs');

fs.readFile("blablabla", {encoding: 'utf-8'}, function(err, data){
    if(err){
        if(err.code == 'ENOENT'){
            console.error(err.message);
        }else{
            console.error(err);
        }
    }else{
        console.log(data);
    }
});

var fs = require('fs');

fs.readFile("blablabla", {encoding: 'utf-8'}, function(err, data){

if(err){

if(err.code == 'ENOENT'){

console.error(err.message);

}else{

console.error(err);

}

}else{

console.log(data);

}

});

то обработать его определенным образом, а иначе сделать что то еще.

Если в будущем вас заинтересует какие еще ошибки есть, или вы захотите получить расшифровку какого то кода ошибки, то к сожалению в документации к Node.JS эта информация отсутствует. Но вы найдет ее в исходниках к библиотеки LibUV. Эти коды находятся именно здесь, потому что за ввод вывод отвечает библиотека LibUV и она трансформирует различные коды операционных систем в вот такие кроссплатформенные значения.

Если мы заведомо знаем, что файл может не существовать, то мы можем проверить его при помощи специального вызова. Для этого есть вызов fs.stat(path, callback) и различные его варианты, которые вы можете более подробно изучит в документации. Как правило в большинстве ситуаций подходит просто stat. Он получает путь и возвращает объект специального типа fs.Stats, который содержит подробную информацию о том, что по нему находится. Вот пример его использования

var fs = require('fs');

fs.stat(__filename, function(err, stats){
    console.log(stats.isFile());
    console.log(stats);
})

var fs = require('fs');

fs.stat(__filename, function(err, stats){

console.log(stats.isFile());

console.log(stats);

})

запускаю

console.log первый, вывело true, по тому что это файл, а второй вывел полную информацию о том, что такое находится по данному пути, это немножко зависит от операционной системы, от файловой системы, но практически всегда есть размер — size, а также модификация — mtime и дата создания — ctime.

А вот пример создания нового файла, в котором будет содержаться строка data, после чего мы его переименовываем, а после переименования удаляем.

var fs = require('fs');

fs.writeFile("file.tmp", "data", function(err){
    if(err)throw err;
    
    fs.rename("file.tmp", "new.tmp", function(err){
        if(err) throw err;
        
        fs.unlink("new.tmp", function(err){
            if(err) throw err;
        });
    });
    
});

var fs = require('fs');

fs.writeFile("file.tmp", "data", function(err){

if(err)throw err;

fs.rename("file.tmp", "new.tmp", function(err){

if(err) throw err;

fs.unlink("new.tmp", function(err){

if(err) throw err;

});

Обратите внимание, что в каждом callback я проверяю ошибку, то есть после того как файл создан, я обязательно проверяю, если есть ошибка, нужно ее как то обработать, самый простейший способ это throw. Везде, в каждом callback должна быть обработка ошибок. Потому что ошибки могут быть в самых непредсказуемых местах.

Итак мы кратко познакомились с основными возможностями модуля «FS» и с некоторыми примерами их применения. Вообще же у этого модуля действительно очень много методов, я рекомендую посмотреть их в документации, просто, чтоб понимать, что вообще существует.

22. Таймеры, process.nextTick, ref/unref

Всем привет. Эта глава посвящена таймерам в Node.JS. В ней я постараюсь в первую очередь рассказать о тех различиях, которые есть между таймерами в браузерах и в Node.JS. Для этого я открыл документацию

и мы видим, что несколько методов здесь очень похожи — setTimeout(), setInterval(), clearTimeout(), clearInterval(), работают практически одинаково, что в Node.JS, что в браузерах. А вот дальше уже начинаются различия. И первое отличие, мы посмотрим на примере такого вот сервера.

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close();
},2500);

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close();

},2500);

Как видим сервер этот очень простой, это можно сказать абстрактный http сервер который слушает порт 3000 и что то там делает, неважно что, с запросами. В определенный момент, например через две с половиной секунды, мы решаем прекратить функционирование этого сервера. При вызове server.close() сервер прекращает принимать новые соединения, но пока есть принятые, но не оконченные запросы они еще будут обрабатываться и только когда все соединения будут обработаны и закрыты, тогда процесс прекратится. В данном случае, я запускаю наш сервер, предварительно создав новую конфигурацию для запуска ref.js в качестве сервера, и если никаких запросов нет, то через две с половиной секунды процесс завершится. Все пока понятно, все предсказуемо.

А теперь предположим, что по мере работы этого сервера я хочу постоянно получать информацию об используемой памяти, в консоле. Что ж, нет ничего проще.

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close();
},2500);

setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close();

},2500);

setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

Каждую секунду выводим, есть специальный вызов «process.memoryUsage()». Итак запускаем и смотрим,

выводит информацию, сервер работает, работает, работает, пока я его не остановил вручную, но в чем же дело? Почему процесс не завершился? Ведь прошло больше чем две с половиной секунды. Конечно же во всем виноваты вот эти строки.

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close();
},2500);

setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

Как мы помним, за таймеры, за события ввода-вывода отвечает библиотека LibUV и пока есть активный таймер LibUV не может завершить процесс. Что делать? Давайте рассмотрим несколько решений.
Первое решение, это сделать callback функции close, которая сработает когда сервер полностью закроет и обработает все соединения и в нем написать «process.exit()»

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close(function(){
        process.exit();
    });
},2500);

setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close(function(){

process.exit();

});

},2500);

setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

Давайте ка попробуем

работает. С одной стороны нормально, с другой, как то это слишком уж брутально, это просто жесткое прибивание процесса. Давайте чуть чуть мягче, сделаем «clearInterval(timer)», будем очищать конкретно вот этот таймер

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close(function(){
        clearInterval(timer);
    });
},2500);

var timer = setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close(function(){

clearInterval(timer);

});

},2500);

var timer = setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

ну ка

тоже все хорошо, но архитектурно и это решение не самое лучшее. Потому что, подумаем, вот сервер

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close(function(){
        clearInterval(timer);
    });
},2500);

var timer = setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close(function(){

clearInterval(timer);

});

},2500);

он может быть в одном файле, а этот setInterval(),

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close(function(){
        clearInterval(timer);
    });
},2500);

var timer = setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

var timer = setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

он может быть, вообще, в другом модуле. А может быть еще и третий модуль, который тоже держит какой то свой сервер или осуществляет какие то свои операции. Что ж clearInterval(). Теперь просто остановится вывод этих сообщений, но другие операции продолжат выполняться, это чуть лучше, но все равно не так хорошо.

На самом деле, правильное решение будет в использовании специализированных возможностей Node.JS. А именно, вот здесь я оставлю close() как и было, а для setInterval(), я использую специальный метод, который называется timer.unref();

var http = require('http');

var server = new http.Server(function(req, res){
    /*обработка запросов*/
}).listen(3000);

setTimeout(function(){
    server.close();
},2500);

var timer = setInterval(function(){
    console.log(process.memoryUsage());
}, 1000);

timer.unref();

var http = require('http');

var server = new http.Server(function(req, res){

/*обработка запросов*/

}).listen(3000);

setTimeout(function(){

server.close();

},2500);

var timer = setInterval(function(){

console.log(process.memoryUsage());

}, 1000);

timer.unref();

Как видим, в отличии от браузерного JavaScript, здесь timer это объект, и метод unref() указывает LibUV, что этот timer является второстепенным, то есть его не следует учитывать при проверки внутренних watcher на завершение процесса. Давайте я запущу

И теперь, как только серверы закончат работу, то есть, как только не останется никаких других внутренних watcher кроме вот этого timer который timer.unref(), процесс, как видим, завершился.
Есть еще метод ref(), он является противоположенным unref(), то есть если я сделал timer.unref(), потом передумал и вызвал timer.ref()то выполнение не прервется, как будто unref() не было.

На практике ref() используется очень редко. Почему это решение лучше? Да просто потому, что здесь timer просто указывает, что он не важен, что по сути нам и требуется. Никаких побочных эффектов это не несет.

Обращаю ваше внимание, что метод unref() есть не только у timer, он есть кроме timer еще например у серверов — server.unref() или у сетевых сокетов — socket.unref(). То есть я могу сделать сетевое соединение, которое тоже не будет препятствовать завершению процесса, если оно почему то не важно.

Далее мы видим методы «setImmediate(callback[, arg][, …])» и «clearImmediate(immediateObject)»

Они тоже отличаются от браузерных. Для того чтобы лучше это понять рассмотрим следующий пример. У нас есть веб сервер и там в функции обработчике запроса понадобилось выполнить какую то операцию асинхронно. В браузере для этого обычно используется либо setTimeout(f,0), либо setImmediate или его эмуляция различными хаками, но обращаю ваше внимание в браузере немножко по другому работает событийный цикл и setImmediate браузерный, немножко не тот, мы сейчас его обсуждать не будем. Посмотрим, что в ноде происходит с setTimeout(f,0), когда сработает этот код. Можем ли мы гарантировать, что он выполнится до того как придет следующий запрос. Конечно же нет! setTimeout() выполнит его в ближайшее время, но совершенно не понятно может быть до следующего запроса, а может и после.

var http = require('http');

http.createServer(function(req, res){
    setTimeout(function(){
        //сработает до следующего запроса или после?
    }, 0);
}).listen(1337);

var http = require('http');

http.createServer(function(req, res){

setTimeout(function(){

//сработает до следующего запроса или после?

}, 0);

}).listen(1337);

Однако, есть такие ситуации когда мы должны четко знать, что некий асинхронный код выполнится до того как в ноду придет следующий запрос или вообще любое следующие событие ввода вывода. Например потому что мы хотим повесить обработчик, скажем у нас есть req и мы хотим повесить на него, в этом setTimeout(), обработчик на следующие данные и мы должны точно знать, что этот обработчик повесится, до того как эти следующие данные будут просчитаны.

var http = require('http');

http.createServer(function(req, res){
    setTimeout(function(){
        req.on('readable', function(){
            // должен сработать на ближайших данных
        })
    }, 0);
}).listen(1337);

var http = require('http');

http.createServer(function(req, res){

setTimeout(function(){

req.on('readable', function(){

// должен сработать на ближайших данных

})

}, 0);

}).listen(1337);

Для решения этой задачи в ноде есть специальный вызов — process.nextTick().

var http = require('http');

http.createServer(function(req, res){
    process.nextTick(function(){
        req.on('readable', function(){
            // должен сработать на ближайших данных
        })
    });
}).listen(1337);

var http = require('http');

http.createServer(function(req, res){

process.nextTick(function(){

req.on('readable', function(){

// должен сработать на ближайших данных

})

});

}).listen(1337);

Он с одной стороны сделает выполнение функции асинхронным, то есть она выполнится после выполнения текущего JavaScript, с другой сторон он гарантирует, что выполнение произойдет, до того как придут следующие события, ввода вывода, timer и так далее.

То есть вот здесь будет это выполнение

и более того, если при обработки этой функции, просто с nextTick(), выяснится, что нужно что то еще, тоже асинхронно запланировать, то вложенные, рекурсивные вызовы, просто с nextTick(), тоже добавят выполнение функции сюда же. Таким образом мы можем гарантировано повесить обработчики и они сработают до того как придут какие то еще данные.

Бывает и другая ситуация, когда мы хотим сделать функцию асинхронной, но при этом не тормозить событийный цикл. Частный пример, это когда у нас есть большая вычислительная задача, то чтобы JavaScript не блокировался здесь на долго

мы можем его попробовать разбить на части. Одну часть запустить тут же, а другую запустить так, чтоб она заработала на следующей итерации этого цикла, и другая на следующей и так далее. Для реализации этого в Node.JS есть метод — setImmediate(callback[, arg][, …]). Этот вызов как раз и планирует вызов функции так, чтоб она с одной стороны сработала как можно скорее, с другой стороны на следующей итерации цикла, после обработки текущих событий.

Рассмотрим отличия между nextTick() и setImmediate(callback[, arg][, …]) на конкретном примере.

var fs = require('fs');

fs.open(__filename, "r", function(err, file){
    console.log("IO!");
});

setImmediate(function(){
    console.log("immediate");
});

process.nextTick(function(){
    console.log("nextTick");
});

var fs = require('fs');

fs.open(__filename, "r", function(err, file){

console.log("IO!");

});

setImmediate(function(){

console.log("immediate");

});

process.nextTick(function(){

console.log("nextTick");

});

Здесь я использую модуль «fs» для того чтобы открыть файл, открытие файла здесь просто как вариант операции ввода вывода. Когда файл будет открыт, то внутреннее событие LibUV которое вызовет эту функцию.

var fs = require('fs');

fs.open(__filename, "r", function(err, file){
    console.log("IO!");
});

setImmediate(function(){
    console.log("immediate");
});

process.nextTick(function(){
    console.log("nextTick");
});

fs.open(__filename, "r", function(err, file){

console.log("IO!");

});

И Дальше я через setImmediate и process.nextTick планирую вывод сообщений. Посмотрим в каком порядке они выведутся. Создам еще одну конфигурацию сервера — io.js и запускаю

Итак, сначала конечно же вывелась nextTick, потому что nextTick планируется по окончанию текущего JavaScript, но до любых событий ввода вывода, то есть до реально открытия файла. setImmediate сработала до вводы вывода, потому что она так запланировала выполнение. А если бы я сюда добавил setTimeout(f,0), где был бы он, а вот неизвестно, может быть и здесь, а может быть и здесь гарантий нет.

Итак мы рассмотрели, чем timer в Node.JS отличаются от браузерных,

1.Это влияние на завершение процесса и методы ref(), unref().
Есть различные setTimeout(f,0) —
2. process.nextTick(f) = setTimeout(f,0) до I/O
3. setImmediate(f) = setTimeout(f,0) после I/O
В большинстве ситуаций используется process.nextTick(f), он гарантирует, что выполнение произойдет до новых событий, в частности до новых операций ввода вывода, до новых данных, как правило это наиболее безопасный вариант. Ну а setImmediate(f) планирует выполнение на следующую итерацию цикла, после обработки событий. Как правило это нужно тогда когда нам без разницы обработаются какие события или нет, то есть мы хотим что то сделать асинхронно и нам не хочется лишний раз тормозить событийный цикл, либо при разбитии сложных задач на части, чтобы одну часть обработать сейчас, другую на следующую итерацию цикла и так далее, при этом получается что задача с одной стороны постепенно делается, а с другой стороны между ее частями могут проскакивать какие то другие события, другие клиенты и серьезной задержки в обслуживании не произойдет.

21. Событийный цикл, библиотека libUV

Если вы привыкли глубоко вникать в происходящее, то эта глава для вас. В ней мы разберем те вопросы, которые рано или поздно обязательно возникнут при разработке и ответы на которые требуют глубокого понимания, как именно работает Node.JS. Например,

var http = require('http');
var fs = require('fs');

// Любые ли операции можно сделать асинхронными?
// Как поступить с теми с которыми нельзя

http.createServer(function(req, res){

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });

    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// Любые ли операции можно сделать асинхронными?

// Как поступить с теми с которыми нельзя

http.createServer(function(req, res){

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}else{/*404*/}

}).listen(3000);

здесь для чтения файла использован асинхронный вызов fs.readFile(), но любые ли операции можно сделать асинхронными? На сколько действительно опасны синхронные вызовы, и что делать если какая то синхронная операция есть и избежать ее никак нельзя, как снизить ее вредный эффект? Что происходит с теми запросами которые приходят пока интерпретатор занят. Например если здесь

var http = require('http');
var fs = require('fs');

// Что происходит с запросами, пока интерпретатор ждет?
//Действительно ли синхронные операции так опасны?

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        try{
            info = fs.readFileSync('index.html');
        }catch(err){
            console.error(err);
            res.statusCode = 500;
            res.end("На сервере произошла ошибка!");
            return;
        }

        res.end(info);
    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// Что происходит с запросами, пока интерпретатор ждет?

//Действительно ли синхронные операции так опасны?

http.createServer(function(req, res){

var info;

if(req.url == '/'){

try{

info = fs.readFileSync('index.html');

}catch(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

}else{/*404*/}

}).listen(3000);

есть синхронное чтение файла и пришло десять клиентов, получают ли они отказ в обслуживании, или выстраиваются в очередь или что то еще. Ответ на эти и не многие другие вопросы мы получим в этой главе.

Для того чтоб глубже понимать происходящее, познакомимся с библиотекой LibUV. Вот ссылочка на доку — http://docs.libuv.org/en/v1.x/

К этой библиотеки не надо обращаться каким то явным образом, она написана на языке «С» и встроена в сервер Node.JS. Библиотека LibUV отвечает за две принципиально важные вещи. Первое это кроссплатформенные операции ввода-вывода — работа с файлами, работа с сетью. Мы через JavaScript даем команду Node.JS — просчитай такой то файл или отправь такие данные по сети, а Node.JS, чтобы это сделать, внутри себя использует библиотеку LibUV. Таким образом LibUV отвечает за кроссплатформенную реализацию этих функций. Именно она уже знает как работать с Windows, работать с Linux и так далее.
Вторая область ответственности LibUV это поддержка основного событийного цикла Node.JS. Оказывается, когда мы запускаем какой то скрипт. то он запускается в режиме цикла. Этот цикл чередует выполнение JavaScript, который обеспечивается виртуальной машиной V8, с ожиданием различных событий ввода-вывода, срабатывания таймеров, за которые так же отвечает библиотека LibUV. И этот цикл будет продолжаться до тех пор, пока возможно появление каких то новых событий, ввода-вывода или таймеров которые нужно будет обработать.

Для примера разберем, что происходит при запуске вот такого сервера

var http = require('http');
var fs = require('fs');

var server = new http.Server();

server.on('request', function(req, res){

    if(req.url == '/'){
        
        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });
    }else{/*404*/}
});

server.listen(3000);

var http = require('http');

var fs = require('fs');

var server = new http.Server();

server.on('request', function(req, res){

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}else{/*404*/}

});

server.listen(3000);

Вначале срабатывает JsvsScript. Он подключает модули ‘http’, ‘fs’, создает объект ‘server’, вешает обработчик — «server.on()», то что внутри обработчика пока не важно, он еще не сработал, и наконец последняя строчка, это вызов команды «listen()». Команда «listen()» это уже команда с сетевыми соединениями. JavaScript команда server.listen(….) попадая в Node.JS проходит через его С++ код, превращается в вызов внутреннего метода TCPWrap::Listen(….), этот внутренний метод уже вызывает библиотеку LibUV, а именно ее метод uv_listen(….), который как раз осуществляет всю работу, то есть он, в зависимости от операционной системы, вешает обработчик соединений на данный порт. Для MacOS, для Unix систем используется системный вызов listen(….).

Таким образом, LibUV назначило обработчик на соединение на этот порт. Этот обработчик, или в терминах LibUV он называется watcher, является внутренним, то есть мы к нему доступа не имеем, это именно LibUV его поставила и когда что то произойдет, например когда придет новое соединение, то watcher сработает, он вызовет соответствующие методы LibUV, Node.JS и в конечном счете даст нам какое то событие, например событие connection. Но это все будет потом, а пока что listen(….) просто повесила обработчик-watcher, результат этого действия подымается по цепочке, если все хорошо, то это приводит к событию listening в JavaScript, если обработчик повесить не удалось, то error.

На этой радостной ноте выполнение JavaScript завершается и LibUV проверяет, есть ли какие то watcher которые могут сработать, есть ли какие то внутренние обработчики, если их нет, то завершается весь процесс Node.JS, завершается весь событийный цикл. Но в нашем случае, один такой watcher, а именно обработчик на порту 3000, был поставлен, именно по этому процесс Node.JS не завершится, а временно заснет и будет спать до какой то причины ему проснуться, например до появления новых событий ввода вывода. Рано или поздно такое событие скорее всего произойдет.

Появится сигнал из операционной системы, что кто то присоединился к порту 3000, внутренний watcher LibUV вызовет соответствующий callback, этот callback передаст сигнал библиотеке LibUV, потом он перейдет в Node.JS, обертка Node.JS тут же сгенерирует событие connection и примется разбирать то, что нам присылают. Далее, если в процессе анализа данных установлено, что это http запрос, то будет сгенерировано событие request и наконец то сработает обработчик server.on(….).

Если получилось так, что url вот такой — if(req.url == ‘/’), то опять же при помощи LibUV инициируется считывание вот этого файла

var http = require('http');
var fs = require('fs');

var server = new http.Server();

server.on('request', function(req, res){

    if(req.url == '/'){

        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });
    }else{/*404*/}
});

server.listen(3000);

var http = require('http');

var fs = require('fs');

var server = new http.Server();

server.on('request', function(req, res){

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}else{/*404*/}

});

server.listen(3000);

Мы отправляем команду в LibUV и JavaScript, на текущий момент закончил работу, все ‘request’ события обработано. Так как JavaScript закончил выполнение и есть внутренние обработчики LibUV, то процесс не прерывается, а снова переходит в состояние спячки. Из этой спячки его могут вывести события, какие? Первое это новый запрос, а второе это завершено чтение файла или какая то ошибка возникла, это нам не так важно сейчас. Когда что то из этого произойдет, то будет вызван соответствующий callback. Получается, что наш код на языке JavaScript, выступает в роли этакого рулевого, он говорит LibUV, инициируй какой то процесс, например чтение файла или получай соединение на таком то порту, LibUV умеет это правильно передать операционной системе, и дальше уже операционная система занимается всякими такими делами, а LibUV ждет пока та ответит, LibUV может делать много таких операций одновременно, уведомляет о результатах JS. Когда операционная система ответит, то LibUV опять же вызывает наш JavaScript код который разруливает ситуацию, возможно инициирует какие то новые процессы ввода-вывода и и дальше процесс опять переходит в состояние спячки и так по циклу.

Казалось бы все более менее ясно, на самом деле есть еще некоторые нюансы. Например представим себе, что первое событие которое здесь произошло

это мы получили новый запрос, и вот управление переходит в JavaScript и вдруг во время выполнения JavaScript происходит завершение чтения файла, срабатываю внутренние обработчики LibUV, но JavaScript то занят, по этому внутреннее событие LibUV стало в очередь и получается так, что пока JavaScript занят каким то делом, внутри LibUV может возникнуть целая очередь событий, которые ожидают обработки. Когда JavaScript закончит работу, он посмотрит в эту очередь возьмет первое событие из нее и обработает, потом опять посмотрит в очередь, опять возьмет и обработает, и так далее, то есть обработка внутренних событий LibUV будет осуществляться последовательно. Например если мы обрабатываем запрос для Пети, а в это время завершилось чтение файла для трех других пользователей, то есть возникло три новых внутренних события, то они стали вот здесь вот в очередь

И будут обработаны последовательно по мере освобождения JavaScript. При этом не смотря на то что очередь событий одна, путаницы никогда не возникнет, потому что когда запускается соответствующий callback — » function(err, info){ …. });» то информацию о том, что это за запрос мы берем из замыкания джаваскриптового. То есть если запустился callback для Паши то тут — «server.on(‘request’, function(req, res){» будет req для Паши. Для Маши callback запустился, это уже другая функция, другое замыкание, соответственно будет продолжаться обработка и будет ответ прислан Маше.

С другой стороны получается так, что для того чтоб работа сервера была наиболее эффективной, JavaScript должен выполняться очень быстро, то есть чтобы никакие новые события не накапливались не ждали. Ну а что будет если JavaScript почему то затормозил. например есть какая то тяжелая вычислительная задача и Node.JS занят, события накапливаются? Такая ситуация называется «Event loop starvation» или по русски «Голодание событийного цикла». При этом обработка всех клиентов которые от них зависят притормозится, что конечно же не очень то хорошо. Для того чтобы обойти эту проблему, тяжелые вычисления обычно выделяют, или в отдельный процесс, или в отдельный поток, либо запускают сам сервер Node.JS в режиме множества процессов, например это можно сделать используя встроенный модуль «cluster», но не только. Еще один вариант, это разбить тяжелую вычислительную задачу на части, то есть например часть ответа можно сгенерировать вот в функции server.on(…), потом через setTimeout(10), отложить генерацию следующей части ответа, и так далее, и так далее. Соответственно при этом получится, что работа в сумме выполняется такая же, но вот выполнение JavaScript разрывается и в промежутке между этими вычислениями, сервер может делать что то еще, например обрабатывать других клиентов. Так или иначе, все эти решения добавляют сложности по этому Node.JS используется в первую очередь там, где тяжелых вычислений не нужно, а где требуется в первую очередь обмен данными. Практика показывает, что это большая часть задач связанных с веб разработкой.

Итак подведем итоги

Сердцем Node.JS является библиотека LibUV. В этом и сила и слабость Node.JS. С одной стороны LibUV позволяет делать много операций ввода-вывода одновременно, то есть наш JavaScript код, может инициировать операцию и дальше заниматься другими делами. Таким образом множество операций ввода-вывода могут обрабатываться одновременно операционной системой, а JavaScript будет пересылать данные от одного клиента к другому, от базы данных клиенту и так далее, просто, эффективно. С другой стороны, это все требует асинхронной разработки, то есть не «readFileSync()», а «readFile()» например. Принятая в Node.JS система колбеков, с одной стороны достаточно проста, с другой стороны она все равно сложнее, чем просто последовательные команды синхронной разработки. Кроме того, так как JS процесс должен обрабатывать кучу событий, то желательно,чтоб он не ждал, чтоб он все делал быстро, быстро, быстро. Чтоб очередь событий не накапливалась. Эту особенность работы Node.JS стоит иметь ввиду с самого начала разработки веб приложения, потому что казалось бы, ну какие у нас сложные вычислительные операции, что у нас там заблокирует JavaScript? А например. Парсинг большого JSON или например подсчет MD5 суммы большого файла закаченного. Еще раз обращаю ваше внимание, эти задачи влияют на производительность сервера еще до того как JavaScript, который их выполняет, съест 100% процессора. То есть Node.JS может кушать 20%, но работать не достаточно эффективно просто из за того, что пока JavaScript занят другие задачи, даже те кому нужны другие ресурсы, скажем база данных, не могут продолжить выполнение. Для того чтобы как то защититься от этого, обычно запускают Node.JS приложение в режиме множества процессов. Как это сделать? Мы разберем в одной из следующих глав.

20. Введение в асинхронную разработку

В реальной жизни очень редко бывает так, что получив запрос, сервер тут же может на него ответить, обычно для того, чтобы ответить серверу нужны какие то данные. Эти данные он получает либо из базы, либо из другого источника, например из файловой системы. Здесь, в этом примере

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        info = fs.readFileSync('index.html');
        res.end(info);
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

var info;

if(req.url == '/'){

info = fs.readFileSync('index.html');

res.end(info);

}

}).listen(3000);

используя модуль fs, при получении запроса на такой ‘/’ url, считывается файл ‘index.html’ и выводится посетителю. Обращаю ваше внимание, ‘fs’ здесь взято для примера, вместо вот такого запроса — «fs.readFileSync(‘index.html’);», здесь мог быть запрос к базе данных или какая то другая операция, которая потребует существенного времени ожидания, в данном случае, это ожидание ответа от диска. Если бы это был запрос к базе данных, это было бы ожидание ответа по сети от базы. Наш код с одной стороны будет работать, с другой стороны в нем есть проблема, связана с масштабируемостью, которая неизбежно проявится в серьезной, промышленной эксплуатации. Например, Петя зашел по этому url — ‘/’ и запросил файл — «fs.readFileSync(‘index.html’);», Петя ждет пока сервер ему ответит и сервер ждет пока файл прочитается и готов ему выслать данные. В это время заходит Вася, Маша и куча другого народу, которые тоже хотят, что то от сервера, например они хотят не вот этот файл, а они хотят вообще, что то другое, скажем получить текущую дату, которую по идеи можно взять и тут же вернуть

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        info = fs.readFileSync('index.html');
        res.end(info);
    }else if(req.url == '/now'){
        res.end(new Date().toSring());
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

var info;

if(req.url == '/'){

info = fs.readFileSync('index.html');

res.end(info);

}else if(req.url == '/now'){

res.end(new Date().toSring());

}

}).listen(3000);

Но сервер не может это сделать, поскольку сейчас, его интерпретатор javascript занят, он ожидает ответа от диска — «fs.readFileSync(‘index.html’);». Когда этот ответ получен он может продолжить выполнение, и выполнить следующую строчку — «res.end(info);», закончить наконец обработку запроса и тогда JavaScript освободится и сможет обработать какие то еще запросы. В результате мы имеем ситуацию, когда одна операция требующая долгого ожидания фактически парализует работу сервера, что конечно же неприемлемо. Только поймите меня правильно, сам по себе вызов, вполне нормальный и такие — «fs.readFileSync(‘index.html’);» — синхронные вызовы замечательно работают если нам нужно делать консольный скрипт. В котором, например, мы должны прочитать файл, потом там с ним что то сделать, потом там его куда то записать и так далее. То есть когда мы должны последовательно сделать ряд задач, связанных с файлами, то такие вызовы, это замечательно, это просто и удобно. Проблемы с ними возникают лишь в серверном окружении, когда нужно делать много вещей одновременно. По этому здесь нужно воспользоваться другим методом, который тоже есть в модуле «fs» и который работает Асинхронно. Иначе говоря, асинхронный метод сразу ничего не возвращает обычно, но вместо этого он инициирует чтение файла, получает аргумент-функцию которой он этот файл передаст когда закончит процесс —

fs.readFile('index.html', function());

1	fs.readFile('index.html', function());

относительно этой функции есть следующее соглашение — если чтение прошло успешно, то функция будет вызвана с первым аргументом null, а во втором аргументе будет содержимое файла. Но если произошла ошибка, то функция будет вызвана, только с первым аргументом, в котором будет информация о ней. Таким образом мы даем вот такую

fs.readFile('index.html', function(err, info){
    
});

fs.readFile('index.html', function(err, info){

});

задачу Node.JS и после этого выполнение продолжается. При этом просчитывать мы будем конечно же вот здесь

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){
            res.end(info);
        });
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

var info;

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

res.end(info);

});

}

}).listen(3000);

Такое решение полностью снимает проблему блокировки. По скольку теперь, интерпретатор JavaScript вовсе не будет ждать пока файл прочитается, он тут же продолжит выполнение и сможет заняться другими посетителями.

Функцию которую Node.JS обязуется вызвать когда завершит процесс, называют функцией обратного вызова или по английски — callback function, или просто callback. Важный подводный камень состоит в том, что о возможности ошибки при таком вызове, можно легко забыть. Например, посмотрим что будет, если файл ‘index.html’, почему то отсутствует. Либо была какая то ошибка при чтении скажем, или с правами, или с диском. В этой ситуации модуль «fs» вызовет callback с первым аргументом, с объектом ошибки, а второго аргумента вообще не будет. Если мы ошибку никак не обрабатываем, то получится что посетитель получит вообще пустую строку. Вот как будто вот такой вызов

res.end(undefined);

1	res.end(undefined);

что в принципе работает так же как и вот эта

res.end(' ');

1	res.end(' ');

Кошмар ситуации в том, что код просто, тихо сглючит, без всяких сообщений об ошибке. При этом, это во первых, может стать известным не сразу, то есть будут какие то жалобы и недовольные люди, а во вторых, будет достаточно сложно отладить это, найти причину, опять же, потому что все очень тихо. Соответственно, чтоб такого не происходило, нужно обязательно обрабатывать аргумент-ошибку. В крайнем случае если мы уж точно уверены, что ошибки, ну никогда не будет (ха ха ха — посмеялись поколения разработчиков, над этой мыслью), можно сделать вот так

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){ // callback
            if(err) throw err;

            res.end('');
        });
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

var info;

if(req.url == '/'){

fs.readFile('index.html', function(err, info){ // callback

if(err) throw err;

res.end('');

});

}

}).listen(3000);

Но в данном случае будет более правильным сделать вот такой вариант

var http = require('http');
var fs = require('fs');

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){ // callback
            if(err) {
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }
            res.end(info);
        });
    }
}).listen(3000);

var http = require('http');

var fs = require('fs');

http.createServer(function(req, res){

var info;

if(req.url == '/'){

fs.readFile('index.html', function(err, info){ // callback

if(err) {

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}

}).listen(3000);

Итак, в завершении этой главы, сравним синхронный и асинхронный код используя для примера реализацию сервера.

Синхронный вариант

var http = require('http');
var fs = require('fs');

// 1. Блокирует => используется там, где нет параллелизма
// 2. Работает try..catch
// 3. Прост и понятен всем :)

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        try{
            info = fs.readFileSync('index.html');
        }catch(err){
            console.error(err);
            res.statusCode = 500;
            res.end("На сервере произошла ошибка!");
            return;
        }

        res.end(info);
    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// 1. Блокирует => используется там, где нет параллелизма

// 2. Работает try..catch

// 3. Прост и понятен всем :)

http.createServer(function(req, res){

var info;

if(req.url == '/'){

try{

info = fs.readFileSync('index.html');

}catch(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

}else{/*404*/}

}).listen(3000);

Асинхронный вариант

var http = require('http');
var fs = require('fs');

// 1. Не блокирует
// 2. Не работает try..catch => callback(err)
// 3. Сложнее (есть способы упростить себе жизнь)

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });

    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// 1. Не блокирует

// 2. Не работает try..catch => callback(err)

// 3. Сложнее (есть способы упростить себе жизнь)

http.createServer(function(req, res){

var info;

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}else{/*404*/}

}).listen(3000);

Начнем с синхронного. Синхронные вызовы, типа

info = fs.readFileSync()

1	info = fs.readFileSync()

Используются достаточно редко, они применяются в тех случаях, когда мы можем себе позволить заблокировать интерпретатор JavaScript. Как правило это значит, что нет параллелизма. Например консольный скрипт, сделай первое, второе, третье и так далее. Синхронный вызов заставляет наш интерпретатор ждать, потом он ответ пишет в «info», если какая то ошибка вышла, то это исключение и оно отлавливается при помощи try..catch.

Асинхронный вариант работает по другому. Тут видите другой вызов

fs.readFile()

1	fs.readFile()

и для того, чтобы получить результат, в асинхронном коде, используется функция обратного вызова. При этом обертывать вот этот вызов

var http = require('http');
var fs = require('fs');

// 1. Не блокирует
// 2. Не работает try..catch => callback(err)
// 3. Сложнее (есть способы упростить себе жизнь)

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });

    }else{/*404*/}
}).listen(3000);

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

в try..catch, не имеет особого смысла. То есть, конечно можно, но с другой стороны, при вызове «fs.readFile()», собственно ошибки никакой не возникнет. Этот метод устроен так, что работает, что работает асинхронно и все ошибки передает в callback. На эту тему в Node.JS есть соглашение, все встроенные модули ему следуют и мы тоже, что первый аргумент функции-обработчика является всегда ошибкой.

То есть вот эта функция, назову ее «cb» для наглядности

fs.readFile('index.html', function cb (err, info){
    if(err){
        console.error(err);
        res.statusCode = 500;
        res.end("На сервере произошла ошибка!");
        return;
    }

    res.end(info);
});

fs.readFile('index.html', function cb (err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

Будет при ошибке вызвана так

fs.readFile('index.html', function cb (err, info){
    // cb(err)

    if(err){
        console.error(err);
        res.statusCode = 500;
        res.end("На сервере произошла ошибка!");
        return;
    }

    res.end(info);
});

fs.readFile('index.html', function cb (err, info){

// cb(err)

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

А если ошибки нет, то она будет вызвана так — «cb(null, ….)» первый аргумент будет null, а во втором уже будут какие то результаты.

Соответственно важное отличие между синхронным и асинхронным вариантом, здесь в том, что если мы в синхронном варианте, вдруг забыли try…catch, то при ошибке, это обязательно станет нам известным, исключение просто выпадет от сюда

var http = require('http');
var fs = require('fs');

// 1. Блокирует => используется там, где нет параллелизма
// 2. Работает try..catch
// 3. Прост и понятен всем :)

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        try{
            info = fs.readFileSync('index.html');
        }catch(err){
            console.error(err);
            res.statusCode = 500;
            res.end("На сервере произошла ошибка!");
            return;
        }

        res.end(info);
    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// 1. Блокирует => используется там, где нет параллелизма

// 2. Работает try..catch

// 3. Прост и понятен всем :)

http.createServer(function(req, res){

var info;

if(req.url == '/'){

try{

info = fs.readFileSync('index.html');

}catch(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

}else{/*404*/}

}).listen(3000);

и повалит процесс в данном коде.
А здесь

var http = require('http');
var fs = require('fs');

// 1. Не блокирует
// 2. Не работает try..catch => callback(err)
// 3. Сложнее (есть способы упростить себе жизнь)

http.createServer(function(req, res){
    var info;

    if(req.url == '/'){
        fs.readFile('index.html', function(err, info){
            if(err){
                console.error(err);
                res.statusCode = 500;
                res.end("На сервере произошла ошибка!");
                return;
            }

            res.end(info);
        });

    }else{/*404*/}
}).listen(3000);

var http = require('http');

var fs = require('fs');

// 1. Не блокирует

// 2. Не работает try..catch => callback(err)

// 3. Сложнее (есть способы упростить себе жизнь)

http.createServer(function(req, res){

var info;

if(req.url == '/'){

fs.readFile('index.html', function(err, info){

if(err){

console.error(err);

res.statusCode = 500;

res.end("На сервере произошла ошибка!");

return;

}

res.end(info);

});

}else{/*404*/}

}).listen(3000);

если мы забыли обработать ошибку, то оно будет глючить и глючить страшным образом и мы просто не получим информации об этом. Соответственно очень важно при асинхронной разработке обязательно обрабатывать ошибки, хоть как то.

Конечно же асинхронная разработка сложнее, нужно какие то функции обратного вызова делать, но вместе с тем, здесь есть свои способы упростить жизнь, которые мы рассмотрим в следующих главах.

19. Логирование, модули debug и winston

Наша следующая тема логирование или иначе говоря отладочный вывод. Когда проект маленький, то вполне достаточно console.log для того, чтобы что-то вывести. Однако проект имеет свойство расти. Например, тот же server.js естественным образом разделяется на сервер и обработчик запроса — request. Со временем появляется работа с пользователем, база данных и так далее. Каждый файл может захотеть по ходу своего выполнения, что-то вывести. И этот вывод для нас очень важен, поскольку показывает, что происходит. Особенно, если что-то происходить не так. В текущем коде, везде используется console.log для вывода

var http = require('http');

var server = http.createServer();

server.on('request', requre('./request'));

server.listen(1337);

console.log("Server is running");

var http = require('http');

var server = http.createServer();

server.on('request', requre('./request'));

server.listen(1337);

console.log("Server is running");

var url = require('url');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    console.log("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        console.log("Echo: " + message);
        res.end(message);
        return;
    }

    console.log("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

var url = require('url');

module.exports = function(req, res) {

var urlParsed = url.parse(req.url, true);

console.log("Got request", req.method, req.url);

if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){

var message = urlParsed.query.message;

console.log("Echo: " + message);

res.end(message);

return;

}

console.log("Unknown URL");

res.statusCode = 404;

res.end('Not Found');

}

Это означает, что перейдя по браузерному url, я получу однообразную кашу из всех записей, что делает скрипт.

Server is running
Got request GET /echo?message=TEST
Echo: TEST
Got request GET /favicon.ico
Unknown URL

Server is running

Got request GET /echo?message=TEST

Echo: TEST

Got request GET /favicon.ico

Unknown URL

Какая из этих записей сделана каким модулем, совершенно не понятно. Иногда конечно можно примерно сообразить, но вообще говоря не очевидно. А по мере появления новых модулей, будет менее очевидно, логи будут расти, соответственно найти то что нас интересует будет все сложнее. Кроме того нужен какой то способ включить вывод только в определенных файлах, в тех, которые нас в данный момент интересуют, в которых могут быть ошибки, которые мы сейчас разрабатываем.

Для этого используются специализированные модули. Рекордсмен по простоте, это модуль DEBUG.

Модуль debug

Давайте поставим его в наш проект. Для этого вспоминаем главу — 7. Введение в NPM — менеджер пакетов для Node.JS и в консоле, из директории проекта, вводим команду

C:\node\server>npm install debug

1	C:\node\server>npm install debug

получаем

как видим NPM создал, как в общем то и ожидалось, директорию «node_modules» в корне нашего проекта

куда и поставил новый модуль, «debug». Давайте теперь подключим его, добавив такую строку

var debug = require('debug');

1	var debug = require('debug');

но этого мало, при подключении нужно указать идентификатор, которым он будет метить весь вывод из данного файла

var debug = require('debug')('server');

1	var debug = require('debug')('server');

Вот так, в данном случае, пусть это буде ‘server’. Теперь вместо console.log мы пишем debug

var http = require('http');
var debug = require('debug')('server');

var server = http.createServer();

server.on('request', require('./request'));

server.listen(1337);

debug("Server is running");

var http = require('http');

var debug = require('debug')('server');

var server = http.createServer();

server.on('request', require('./request'));

server.listen(1337);

debug("Server is running");

Аналогичную операцию я произвожу и с файлом request.js, только на этот раз идентификатором будет не ‘server’ a ‘server:request’. Обратим внимание на двоеточие в ‘server:request’, это нам еще будет важно

var url = require('url');
var debug = require('debug')('server:request');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    debug("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        debug("Echo: " + message);
        res.end(message);
        return;
    }

    debug("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

var url = require('url');

var debug = require('debug')('server:request');

module.exports = function(req, res) {

var urlParsed = url.parse(req.url, true);

debug("Got request", req.method, req.url);

if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){

var message = urlParsed.query.message;

debug("Echo: " + message);

res.end(message);

return;

}

debug("Unknown URL");

res.statusCode = 404;

res.end('Not Found');

}

Итак, запускаю, сейчас не из WebStorm а через терминал

И мы видим, что ничего не выводит, потому что, чтоб выводило, мне нужно указать, что выводить. Для возврата в исходный режим нажимаем сочетание клавиш «Ctrl + C». И пробуем еще раз, но теперь для передачи информации о том, что выводить, нужно создать переменную окружения с названием «DEBUG» и дать ей значение, для начала, «server»

На эту тему, для пользователей windows, есть интересная статья —

Команда SET — работа с переменными среды Windows

Что произошло? Мы создали переменную которой дали значение, запустили сервер и видим что в консоль дебагом выведено сообщение которое помечено идентификатором «server».

У нас ведь есть еще один файл, который тоже должен выводить, нужную нам, информацию в консоль. Но в фале request.js другой идентификатор, а именно — ‘server:request’, давайте добавим его в нашу переменную. Вводим в консоле

C:\node\server>set DEBUG=server:request,%DEBUG%

1	C:\node\server>set DEBUG=server:request,%DEBUG%

Давайте чуть отвлечемся и проговорим вот такой момент, который сейчас важен. Переменная «DEBUG» имеет значение, это мы уже поняли. Это значение это строка. И если до последней команды в консоле, эта строка была равна «DEBUG=server», то после она стала равной «DEBUG=server:request,server». Как видим последней командой мы дописали значение в начало этой строки.

От сюда делаем два вывода —

во первых принципиально важно не забыть поставить запятую после выражения которое мы хотим добавить к нашей строке, потому что именно по запятым парсится значение переменной DEBUG, и отделяя запятыми мы перечисляем идентификаторы которыми помечены интересующие нас логи, прямо как точка с запятой — «;» в переменной «PATH».
во вторых если у нас вдруг появится файл «user.js» и в нем мы подключим модуль «debug» которому укажем идентификатор, скажем, «user», то нам нужно будет опять проделать такую операцию

console
JavaScript

C:\node\server>set DEBUG=user,%DEBUG%

1

C:\node\server>set DEBUG=user,%DEBUG%

если мы хотим выводить логи из этого файла.

К стати проверить значение переменной можно в любой момент, введя в консоле такую команду

C:\node\server>set debug

1	C:\node\server>set debug

Просто set и имя переменной, вот такая многогранная команда «set».

И так возвращаемся к нашему серверу. Мы добавили значение в переменную DEBUG

теперь посмотрим какое значение имеет переменная DEBUG

Судя по значению должно выводить логи из обоих файлов, проверим

запустили сервер и он сразу вывел лог помеченный идентификатором ‘server’. Теперь перезагрузим открытую в браузере страницу по адресу — «http://127.0.0.1:1337/echo?message=TEST«, смотрим в консоль

вот и второй файл и логи в нем отработали.

К стати если мы уже решили выводить абсолютно все логи, то можно значение переменной DEBUG установить равной «*». Давайте установим, убедимся чему равно и запустим сервер. И не забываем, чтоб прервать работу сервера из консоли, достаточно нажать сочетание клавиш «Ctrl + C». Итак смотрим

Теперь перезагрузим открытую в браузере страницу по адресу — «http://127.0.0.1:1337/echo?message=TEST» и смотрим в консоль

Все работает по прежнему.

Модуль winston

Модуль DEBUG это с одной стороны простое и гибкое решение задачи логгинга, с другой стороны он иногда уж слишком прост например в файле request.js у нас дебагом обозначены сообщения, важность которых совершенно различная. Скажем эта информация

var url = require('url');
var debug = require('debug')('server:request');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    debug("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        debug("Echo: " + message);
        res.end(message);
        return;
    }

    debug("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

debug("Got request", req.method, req.url);

может быть средней важности при отладке. Эта информация

var url = require('url');
var debug = require('debug')('server:request');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    debug("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        debug("Echo: " + message);
        res.end(message);
        return;
    }

    debug("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

var message = urlParsed.query.message;

debug("Echo: " + message);

res.end(message);

может быть неважной. Эта информация может быть очень важной

var url = require('url');
var debug = require('debug')('server:request');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    debug("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        debug("Echo: " + message);
        res.end(message);
        return;
    }

    debug("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

debug("Unknown URL");

поскольку, это ошибка — url не найден.

При помощи DEBUG задать важность, каким то образом нельзя. Кроме того DEBUG все пишет в стандартный поток вывода, а мы можем захотеть писать в файл или базу данных. Если такая потребность возникла или планируется, что она возникнет, тогда имеет смысл взглянуть на более навороченный модуль для логирования, который называется «Winston».

Ставим его

и заменяем в коде require(‘debug’) на require(‘winston’), который возвращает объект «log».

var url = require('url');
var log = require('winston');

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    log.info("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        log.debug("Echo: " + message);
        res.end(message);
        return;
    }

    log.error("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
}

var url = require('url');

var log = require('winston');

module.exports = function(req, res) {

var urlParsed = url.parse(req.url, true);

log.info("Got request", req.method, req.url);

if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){

var message = urlParsed.query.message;

log.debug("Echo: " + message);

res.end(message);

return;

}

log.error("Unknown URL");

res.statusCode = 404;

res.end('Not Found');

}

Для того чтобы логировать, я должен вызвать соответствующий метод этого объекта

log.debug — Маленькой важности
log.info — Сообщение средней важности.
log.error — это ошибка.

Все ошибки считаются очень важными, кроме того логгер настроен так, что по умолчанию он выводит сообщения только уровня info и более важные. Сейчас мы это увидим, запускаю в WebStorm и в браузере перехожу на соответствующий url — «http://127.0.0.1:1337/echo?message=TEST«.

Как и говорилось ранее log.debug вообще не выводится, выводятся только сообщения уровня info и более важные, такие как error.

В модуле «DEBUG» можно было ограничить вывод, только интересующими нас модулями указав их в переменной окружения DEBUG. К сожалению в самом winston такой функциональности нету, по этому ее придется реализовать самим.

var url = require('url');
var log = require('./log')(module);

module.exports = function(req, res) {
    var urlParsed = url.parse(req.url, true);

    log.info("Got request", req.method, req.url);

    if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){
        var message = urlParsed.query.message;
        log.debug("Echo: " + message);
        res.end(message);
        return;
    }

    log.error("Unknown URL");

    res.statusCode = 404;
    res.end('Not Found');
};

var url = require('url');

var log = require('./log')(module);

module.exports = function(req, res) {

var urlParsed = url.parse(req.url, true);

log.info("Got request", req.method, req.url);

if(req.method == 'GET' && urlParsed.pathname == '/echo' && urlParsed.query.message){

var message = urlParsed.query.message;

log.debug("Echo: " + message);

res.end(message);

return;

}

log.error("Unknown URL");

res.statusCode = 404;

res.end('Not Found');

};

Просто сделать обертку над winston, которая будет находиться в отдельном модуле и добавлять интересующею нас функциональность. Назовем этот модуль «log», он будет принимать текущий объект модуля и возвращать по сути тот же winston, но по разному настроенный, в зависимости от того какой именно модуль мы ему передаем, для каких то будем логировать так, для каких то можно логировать по другому. Вот пример такого модуля

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [
            
            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];
        
        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

var winston = require('winston');

module.exports = function(module){

return makeLogger(module.filename);

};

function makeLogger(path){

if(path.match(/request.js$/)){

var transports = [

new winston.transports.Console({

timestamp: true, //function() {return new Date().toString()}

colorize: true,

level: 'info'

}),

new winston.transports.File({

filename: 'debug.log',

level: 'debug'

})

];

return new winston.Logger({

transports: transports

});

}else{

return new winston.Logger({

transport: []

});

}

Он экспортирует функцию, которая принимает модуль для которого нужно сделать логирование и возвращает winston настроенный соответственно его пути

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

module.exports = function(module){

return makeLogger(module.filename);

};

В данном случае настройка заключается в том, что мы смотрим на что заканчивается путь и если это «/request.js» то возвращаем winston настроенный одним способом

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

if(path.match(/request.js$/)){

var transports = [

new winston.transports.Console({

timestamp: true, //function() {return new Date().toString()}

colorize: true,

level: 'info'

}),

new winston.transports.File({

filename: 'debug.log',

level: 'debug'

})

];

return new winston.Logger({

transports: transports

});

а если это что-то другое то другим

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

}else{

return new winston.Logger({

transport: []

});

}

Для настройки winston здесь используется концепция транспортов. Транспорт это нечто, что умеет передавать информацию, в данном случае информацию из логов. Например есть встроенный в winston транспорт «Console»

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

new winston.transports.Console({

timestamp: true, //function() {return new Date().toString()}

colorize: true,

level: 'info'

}),

Который можно настраивать вот так, указать timestamp, расцветить — colorize, level — использовать его только для сообщений уровня info и выше.

Второй транспорт здесь это файл

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

new winston.transports.File({

filename: 'debug.log',

level: 'debug'

})

который записывает логи, как указано, в файл с названием ‘debug.log’ — filename: ‘debug.log’ и будет включаться для сообщений уровня debug и выше — level: ‘debug’. То есть фактически для всех. Таким образом, если путь оканчивается на /request.js, то мы возвращаем winston

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

return new winston.Logger({

transports: transports

});

который будет записывать в консоль сообщения info или выше и в файл вообще все.

ну, а для других путей, мы будем возвращать winston вообще без транспортов.

var winston = require('winston');

module.exports = function(module){
    return makeLogger(module.filename);
};

function makeLogger(path){
    if(path.match(/request.js$/)){
        var transports = [

            new winston.transports.Console({
                timestamp: true, //function() {return new Date().toString()}
                colorize: true,
                level: 'info'
            }),

            new winston.transports.File({
                filename: 'debug.log',
                level: 'debug'
            })
        ];

        return new winston.Logger({
            transports: transports
        });
    }else{
        return new winston.Logger({
            transport: []
        });
    }
}

return new winston.Logger({

transport: []

});

соответствующие вызовы log, с одной стороны не будут вызывать ошибку, а с другой стороны такая запись никуда не пойдет.

Проверяю это, запустив сервер и перейдя в браузере по адресу — «http://127.0.0.1:1337/echo?message=log-me-please» и мы видим

что действительно информация info, попала в консоль, а так же появился файл debug.log, в котором есть все, все сообщения.

Итак мы с вами рассмотрели отладку,

во первых, при помощи модуля debug, который с одной стороны весьма прост, с другой стороны позволяет указать какую ветку кода логировать, и вообще для большинства задач разработки его вполне хватает.

Но если требуется более серьезное логирование, в том числе в несколько мест одновременно, или в базу данных или в файл, тогда имеет смысл обратить внимание на другой модуль, который называется winston. Его можно гибко настраивать в том числе при помощи обертки.

NODE_DEBUG

Следующие средство отладки которое мы сейчас изучим называется NODE_DEBUG=»cluster fs http module net timer tls». NODE_DEBUG это переменная окружения которая используется внутри Node.JS. Есть ряд встроенных модулей которые, если эта переменная стоит, могут показывать, что происходит внутри них. Таким образом NODE_DEBUG, это средство для глубокой отладки. Его используют в тех случаях, когда наши возможности по отладке исчерпаны и нам ничего не остается, кроме как заглянуть внутрь самой ноды и посмотреть, что же там делается внутри.

Например, мы хотим посмотреть, что передается по сети. Для этого нужно запустить ноду, сначала установив переменную окружения

C:\node\server>set NODE_DEBUG="http net"

1	C:\node\server>set NODE_DEBUG="http net"

на этот раз разделяем, значения присваиваемые переменной NODE_DEBUG, пробелами. И запускаем наш server.js. Для MacOs это будет выглядеть вот так

C:\node\server>NODE_DEBUG="http net" node server.js

1	C:\node\server>NODE_DEBUG="http net" node server.js

в этом случае, мы полностью поймем, что внутри сети здесь творится.

Смотрите, я только запустил, не успел никуда зайти, а уже начала поступать информация модуль NET вывел, что мы теперь слушаем все интерфейсы и порт 1337. А теперь перейду по адресу «http://127.0.0.1:1337/echo?message=TEST»

и как видите, я получаю полный отчет, о том, что происходит.

Итак, у нас есть три инструмента логирования, которых хватит как для отладки небольшого проекта, так для полноценного логгинг-решения, ну и на конец, чтобы заглянуть внутрь Node.JS.