Створюємо повноцінний веб-сайт, працюючий на основі зразу MVC, за допомогою ExpressJS

() translation by (you can also view the original English article)

У цьому посібнику ми будемо створювати повноцінний веб-сайт, що складається з призначеної для кінцевого користувача клієнтської частини та панелі керування (* представлена на екрані у вигляді набору піктограм утиліт, які дозволяють настроювати ті або інші функції ОС, пристрої або підсистеми комп'ютера. Тут і надалі примітка перекладача) для керування контентом сайту. Як ви, певно, здогадуєтеся, остаточна робоча версія додатка містить безліч різних файлів. Я написав цей посібник крок за кроком, слідуючи процесу розробки, проте у ньому не розглядається кожний окремий файл, оскільки у цьому випадку посібник став би дуже довгим та скучним. Проте початковий код доступний на GitHub, і я вам дуже раджу вам з ним ознайомитися.

Вступ

Express – один з найкращих фреймворків для Node.js. Для нього створено безліч модулів, і він має набір корисних можливостей. Окрім цього посібника є багато інших чудових посібників, в яких розкриваються всі головні питання розглядуваної у цьому посібнику теми. Проте тут я хочу копнути трохи глибше та поділитися інформацією про те, як у мене організовано процес розроблення повноцінного веб-сайту. У цілому цей посібник присвячений не тільки Express, але й використанню цього фреймворка сумісно з іншими чудовими інструментами, доступними для розробників, працюючих з платформою Node.

Я припускаю, що ви вже знайомі з Node.js, що її вже встановлено на вашому комп'ютері та що ви вже, ймовірно, створили за допомогою неї деякі додатки.

Express працює на основі Connect (* розширюваний фреймворк для створення сервера HTTP для Node.js, в якому використовуються «плаґіни» – ПЗ проміжного шару; починаючи з версії 4.x Express більше не залежить від Connect). Це фреймворк, що надає можливість використання ПЗ проміжного шару (* спосіб інкапсуляції функціональності, особливо функціональності, що працює з HTTP-запитом до вашого додатка. На ділі ПЗ проміжного шару — просто функція, що приймає три аргументи: об'єкт запиту, об'єкт відповіді та функцію next), що містить безліч корисних функціональних можливостей. Якщо ви неясно уявляєте, що таке ПЗ проміжного шару, то ось вам невеликий приклад:

var connect = require('connect'),
    http = require('http');

var app = connect()
    .use(function(req, res, next) {
        console.log("That's my first middleware");
        next();
    })
    .use(function(req, res, next) {
        console.log("That's my second middleware");
        next();
    })
    .use(function(req, res, next) {
        console.log("end");
        res.end("hello world");
    });

http.createServer(app).listen(3000);

ПЗ проміжного шару по суті є функцією, що приймає об'єкти запиту та відповіді і функцію next. За допомогою кожного ПЗ проміжного шару може бути відправлено відповідь завдяки використанню об'єкта response або ж передано керування наступній функції завдяки виклику функції зворотного виклику next. Якщо ви видалите у прикладі вище виклик методу next() у другому ПЗ проміжного шару, рядок «hello world» ніколи не буде відправлено браузеру. Ось так, у цілому, працює Express. Є деяке вбудоване ПЗ проміжного шару, яке, звісно ж, економить вам багато часу (* в Express 4 усі вбудоване ПЗ проміжного шару видалено, за виключенням express.static). Наприклад Body parser, за допомогою якого розбираються тіла запитів і який підтримує наступні типи контенту: application/json, application/x-www-form-urlencoded та multipart/form-data. Або ж Cookie parser, за допомогою якого розбирається заголовок Cookie та встановлюється в якості значення req.cookies об'єкт, ключами якого є назви кукі.

Express, власне, обгортає Connect та додає до нього нові функціональні можливості. Як, наприклад, логіку маршрутизації, завдяки чому процес оброблення запитів набагато полегшується. Нижче наведено приклад оброблення запиту за методом GET.

app.get('/hello.txt', function(req, res){
    var body = 'Hello World';
    res.setHeader('Content-Type', 'text/plain');
    res.setHeader('Content-Length', body.length);
    res.end(body);
});

Встановлення

Є два головних способи встановлення Express. Перший реалізується завдяки вказанню його в якості залежності у вашому файлі package.json та виконанню команди npm install (є жарт, що npm означає no problem man (* без проблем, чувак) :)):

{
    "name": "MyWebSite",
    "description": "My website",
    "version": "0.0.1",
    "dependencies": {
        "express": "3.x"
    }
}

Код фреймворка буде поміщено до папки node_modules, і ви зможете створити його екземпляр. Проте я віддаю перевагу альтернативному варіанту, при якому використовується командний рядок. Просто встановіть Express глобально (* завдяки чому модуль може бути використано в якості інструмента командного рядка незалежно від того, в якій директорії ви знаходитесь) за допомогою команди npm install -g express. Завдяки цьому тепер ми маємо зовсім новий інструмент командного рядка. Наприклад, якщо ви виконаєте наступну команду:

1	express --sessions --css less --hogan app

то за допомогою Express буде створено каркас додатка із заздалегідь налаштованими для вас деякими моментами. Нижче наведено опції, якими можна скористатися при виконанні команди express(1):

Usage: express [options]
Options:
  -h, --help          output usage information
  -V, --version       output the version number
  -s, --sessions      add session support
  -e, --ejs           add ejs engine support (defaults to jade)
  -J, --jshtml        add jshtml engine support (defaults to jade)
  -H, --hogan         add hogan.js engine support
  -c, --css   add stylesheet  support (less|stylus) (defaults to plain css)
  -f, --force         force on non-empty directory

Як ви бачите, доступно лише декілька опцій, проте мені їх достатньо. Звичайно я використовую less в якості препроцесора CSS та hogan в якості шаблонізатора (* ПЗ для комбінування шаблонів з моделлю даних для отримання кінцевих документів). У нашому прикладі також буде потрібна підтримка сесій, що вирішується завдяки додаванню аргумента --sessions. Після завершення виконання вищевказаних команд наш проект виглядає наступним чином:

/public
    /images
    /javascripts
    /stylesheets
/routes
    /index.js
    /user.js
/views
    /index.hjs
/app.js
/package.json

Якщо ви ознайомтеся з файлом package.json, то побачите, що всі потрібні нам залежності додано до нього. Проте їх ще не було встановлено. Для цього просто виконайте npm install, і після цього вони будуть додані до папки node_modules.

Я розумію, що вищезазначений спосіб не завжди підходить. Можливо, ви хочете помістити ваші обробники маршрутів до іншої папки або змінити щось ще. Але як ви побачите у наступних декількох частинах, я внесу зміни до вже згенерованої структури, що дуже просто виконати. Так що ви повинні просто розглядати команду express(1) в якості команди для створення зразка.

FastDelivery

Для цього посібника я створив простий веб-сайт вигаданої компанії під назвою FastDelivery. Нижче наведено скриншот завершеного дизайну:

Під кінець посібника ми будемо мати готовий веб-додаток з робочою панеллю керування. Ідея полягає у тому, щоб реалізувати можливість керування кожною частиною додатка в окремих призначених тільки для певного кола користувачів областях. Макет було створено у Photoshop та зверстано за допомогою коду CSS(less) та HTML(hogan). Тепер ось що: я не буду розглядувати процес верстання, оскільки це не стосується обговорюваної у цьому посібнику теми, проте якщо ви маєте якісь питання з цього приводу, то сміло запитуйте. Після виконання верстання ми маємо наступні файли та структуру додатка:

/public
    /images (there are several images exported from Photoshop)
    /javascripts
    /stylesheets
        /home.less
        /inner.less
        /style.css
        /style.less (imports home.less and inner.less)
/routes
    /index.js
/views
    /index.hjs (home page)
    /inner.hjs (template for every other page of the site)
/app.js
/package.json

Нижче наведено список частин сайту, якими ми будемо керувати:

Home (* Головна сторінка) (банер (заголовок) посередині та текст)
Blog (* Блог) (для додання, видалення та редагування статей)
Services page (* Послуги)
Careers page (* Вакансії)
Contacts page (* Контакти)

Налаштування

Нам потрібно виконати дещо перед тим, як почати власне реалізацію додатка. Мова йде про налаштування конфігурації (* набір апаратних та/або програмних налаштувань (наприклад, положень перемикачів, значень змінних, керуючих послідовностей), визначаючих склад системи або додатка, функціональні можливості та/або режими функціонування пристрою або програми) додатка. Давайте уявимо, що наш невеликий додаток повинен бути доставлений у три різні місця – локальний сервер, допоміжний сервер (* служить для попереднього перегляду та перевірки нового контента перед публікацією на робочих серверах Мережі) та сервер для розміщення фінальної версії додатка. Зрозуміло, що налаштування для кожного середовища відрізняються та нам потрібно реалізувати достатньо гнучкий механізм для переходу між середовищами. Як ви знаєте, кожний скрипт node виконується в якості консольного застосування. Тому ми можемо з легкістю передати аргументи у командному рядку, за допомогою яких буде визначатися поточне середовище. Я оформив частину коду для налаштування конфігурації в якості окремого модуля, щоб написати тест для неї пізніше. Нижче наводиться код файлу index.js, розташованого у папці /config/:

var config = {
    local: {
        mode: 'local',
        port: 3000
    },
    staging: {
        mode: 'staging',
        port: 4000
    },
    production: {
        mode: 'production',
        port: 5000
    }
}
module.exports = function(mode) {
    return config[mode || process.argv[2] || 'local'] || config.local;
}

Поки що у ньому використовуються тільки два налаштування: mode (* режим) та port (* порт). Як ви, напевно, здогадуєтесь, у додатку використовуються різні порти для різних серверів. Тому нам потрібно оновити точку входу (* адреса команди, з якої починається виконання якогось фрагменту коду. Звичайно говорять про точки входу у підпрограму, функцію, драйвер або процедуру) застосування в app.js.

...
var config = require('./config')();
...
http.createServer(app).listen(config.port, function(){
    console.log('Express server listening on port ' + config.port);
});

Для переключення між конфігураціями просто додайте назву потрібного вам середовища у кінці команди. Наприклад, у результаті виконання команди

1	node app.js staging

буде виведено повідомлення

1	Express server listening on port 4000

Тепер всі наші налаштування заходяться в одному місці та ними легко керувати.

Тести

Я великий шанувальник розробки через тестування (* Test-driven development (TDD)) Я спробую розглянути всі використовувані у цьому посібнику головні класи (* модулі). Зрозуміло, що у випадку обговорення тестів для всього коду цей посібник був би занадто довгим, проте у цілому, саме так вам варто поступати при створенні ваших власних застосувань. Один з моїх улюблених фреймворків для тестування – jasmine. Звісно ж, він доступний у реєстрі npm:

1	npm install -g jasmine-node

Давайте створимо папку tests, в якій будуть знаходитися наші тести. Для початку ми протестуємо налаштування конфігурації. Файли з технічними характеристиками (* документ, що описує вимоги, яким мають відповідати продукт або послуга; детальний опис функцій будь-чого (наприклад, програми, стандарту)) повинні закінчуватися на .spec.js, так що файл повинен називатися config.spec.js.

describe("Configuration setup", function() {
    it("should load local configurations", function(next) {
        var config = require('../config')();
        expect(config.mode).toBe('local');
        next();
    });
    it("should load staging configurations", function(next) {
        var config = require('../config')('staging');
        expect(config.mode).toBe('staging');
        next();
    });
    it("should load production configurations", function(next) {
        var config = require('../config')('production');
        expect(config.mode).toBe('production');
        next();
    });
});

Виконайте команду jasmine-node ./tests, і ви повинні будете побачити наступне:

1	Finished in 0.008 seconds
2	3 tests, 6 assertions, 0 failures, 0 skipped

Цього разу я написав спочатку реалізацію і потім тест до неї. Це не зовсім відповідає принципам розробки через тестування, проте у наступних декількох розділах я буду робити навпаки.

Я дуже вам раджу витратити значну кількість часу на написання тестів. Нема нічого кращого, ніж повністю протестований додаток.

Декілька років тому я усвідомив дещо важливе, що може допомогти вам розроблювати якісніші програми. Кожного разу, коли починаєте писати новий клас, новий модуль або просто новий фрагмент логіки, запитайте себе:

Як мені це протестувати?

Відповідь на це запитання допоможе вам підвищити ефективність при написанні коду, створювати кращі API та оформлювати весь код у вигляді акуратно відокремлених блоків. Ви не зможете написати тести для заплутаного коду (* будь-яка погано спроектована, слабко структурована й важка для розуміння програма). Наприклад, у конфігураційному файлі вище (/config/index.js) я додав можливість передачі mode до конструктора модуля. Ви, напевно, на розумієте, навіщо я це роблю, коли головна ідея – отримати значення mode із аргументів командного рядка. Все просто... тому що мені потрібно було протестувати ту функціональну можливість. Давайте уявимо, що місяць по тому мені потрібно перевірити дещо у конфігурації, призначеній для фінальної версії додатка (production), але при цьому запускати скрипт node з параметром staging. Я би не зміг це виконати без того незначного вдосконалення. Той попередній невеликий крок тепер по суті позбавляє мене від проблем у майбутньому.

База даних

Оскільки ми створюємо динамічний веб-сайт, нам потрібна база даних для зберігання у ній наших даних. Я вирішив використовувати mongodb для цього посібника. Mongo – документальна база даних (* упорядкована сукупність взаємопов'язаних документів; база даних, в якій кожний запис відповідає конкретному документу, містить його опис та, можливо, іншу інформацію про нього) NoSQL. Інструкції з встановлення можуть бути знайдені тут, і оскільки я користуюсь Windows, то я замість цього скористався інструкціями для неї. Одразу після встановлення запустіть демон (* прихований від користувача процес (часто виконуваний у фоновому режимі), який викликають під час виконання якоїсь функції (або в конкретний момент часу)) MongoDB, що за налаштуванням прослуховує підключення по 27017 порту. Що ж, теоретично тепер ми повинні мати можливість підключитися до цього порту та обмінятися інформацією з сервером mongodb. Для виконання цього у скрипті node нам потрібний модуль/драйвер mongodb. Якщо ви завантажили файли з початковим кодом для цього посібника, то модуль mongodb вже додано у файлі package.json. Якщо ж ні, то просто додайте "mongodb": "1.3.10" до списку ваших залежностей та виконайте команду npm install.

Далі ми напишемо тест для перевірки того, чи запущено сервер mongodb. Нижче наведено контент файлу mongodb.spec.js, що знаходиться у папці /tests/:

describe("MongoDB", function() {
    it("is there a server running", function(next) {
        var MongoClient = require('mongodb').MongoClient;
        MongoClient.connect('mongodb://127.0.0.1:27017/fastdelivery', function(err, db) {
            expect(err).toBe(null);
            next();
        });
    });
});

Функція зворотного виклику у методі .connect клієнта mongodb отримує об'єкт db. Ми будемо використовувати його пізніше для керування нашими даними, і це означає, що нам потрібен буде доступ до нього всередині наших модулів. Нерозумно створювати новий об'єкт MongoClient кожного разу, коли нам потрібно виконати запит до бази даних. Тому я перемістив код для запуску сервера express до функції зворотного виклику функції connect:

MongoClient.connect('mongodb://127.0.0.1:27017/fastdelivery', function(err, db) {
    if(err) {
        console.log('Sorry, there is no mongo db server running.');
    } else {
        var attachDB = function(req, res, next) {
            req.db = db;
            next();
        };
        http.createServer(app).listen(config.port, function(){
            console.log('Express server listening on port ' + config.port);
        });
    }
});

Ми можемо вдосконалити код ще далі. Оскільки ми маємо налаштування конфігурації, то було би чудово помістити туди значення хоста та порту і потім змінити URL, використовуваний для підключення до бази даних, на:

1	'mongodb://' + config.mongo.host + ':' + config.mongo.port + '/fastdelivery'

Зверніть увагу на ПЗ проміжного шару attachDB, яке я додав одразу перед викликом функції http.createServer. Завдяки цьому невеликому доповненню ми присвоїмо значення властивості .db об'єкта запиту. Хороші новини полягають у тому, що ми можемо підключити декілька функцій при визначення маршруту. Наприклад:

1	app.get('/', attachDB, function(req, res, next) {
2	...
3	})

Так що завдяки цьому Express викликає attachDB перед виконанням нашого обробника маршруту. Одразу після цього об'єкту запиту буде додано властивість .db, і ми можемо його використовувати для доступу до бази даних.

MVC

Всі ми знайомі зі зразком MVC (* Model-View-Controller – Модель-Представлення-Контролер. Архітектурний зразок програмного забезпечення, який звичайно використовується для розробки користувальницьких інтерфейсів, згідно з яким додаток поділяється на три частини). Питання полягає у тому, як це стосується Express. У цілому це залежить від інтерпретації. У наступних декількох розділах я створю модулі, які будуть виконувати роль моделі, представлення та контролера

Модель

Модель – те, за допомогою чого ми будемо керувати наявними у нашому додатку даними. Вона повинна мати доступ до об'єкта db, який повертає MongoClient. У нашій моделі також повинен бути метод для її розширення, оскільки ми можемо захотіти створити різні типи моделей. Наприклад, ми би могли захотіти створити BlogModel або ContactsModel. Так що нам потрібно написати нові технічні характеристики – /tests/base.model.spec.js для того, щоб протестувати ці дві можливості моделі. І пам'ятайте, що завдяки визначенню цих функціональних можливостей перед їх реалізацією ми можемо гарантувати, що наш модуль буде виконувати тільки те, що нам потрібно.

var Model = require("../models/Base"),
    dbMockup = {};
describe("Models", function() {
    it("should create a new model", function(next) {
        var model = new Model(dbMockup);
        expect(model.db).toBeDefined();
        expect(model.extend).toBeDefined();
        next();
    });
    it("should be extendable", function(next) {
        var model = new Model(dbMockup);
        var OtherTypeOfModel = model.extend({
            myCustomModelMethod: function() { }
        });
        var model2 = new OtherTypeOfModel(dbMockup);
        expect(model2.db).toBeDefined();
        expect(model2.myCustomModelMethod).toBeDefined();
        next();
    })
});

Замість передачі справжнього об'єкта db я вирішив передати його імітацію. Я це зробив, оскільки мені може знадобитися протестувати щось конкретне, що залежить від інформації, яка надходить з бази даних. Буде набагато простіше визначити ці дані вручну.

Реалізувати метод extend трохи складнувато, оскільки нам потрібно змінити прототип module.exports, але як і раніше зберегти початковий конструктор. На щастя, у нас вже написано чудовий тест, за допомогою якого підтверджується, що наш код працює. Версія модуля, яка проходить вищевказаний тест, виглядає наступним чином:

module.exports = function(db) {
    this.db = db;
};
module.exports.prototype = {
    extend: function(properties) {
        var Child = module.exports;
        Child.prototype = module.exports.prototype;
        for(var key in properties) {
            Child.prototype[key] = properties[key];
        }
        return Child;
    },
    setDB: function(db) {
        this.db = db;
    },
    collection: function() {
        if(this._collection) return this._collection;
        return this._collection = this.db.collection('fastdelivery-content');
    }
}

Тут ми маємо два допоміжних методи. Сеттер для об'єкта db та геттер для нашої колекції бази даних.

Представлення

Представлення відобразить інформацію на екран. По суті, представлення – клас, що відправляє відповідь браузеру. Express надає легкий спосіб для виконання цього:

1	res.render('index', { title: 'Express' });

Об'єкт відповіді – обгортка з чудовим API, що полегшує нам життя. Проте я би краще створив модуль, що інкапсулював би цей функціонал: Ми замінимо задану за налаштуванням папку для представлень views на templates та створимо нове представлення, в якому буде розташовуватися клас представлення Base. Для виконання цієї невеликої зміни потрібно внести ще одну. Нам потрібно вказати Express, що наші файли шаблонів тепер розташовуються в іншій папці:

1	app.set('views', __dirname + '/templates');

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

Його конструктор повинен отримати об'єкт відповіді та ім'я зразка.
Він повинен мати метод render, що приймає об'єкт з даними.
У нього повинна бути можливість розширення.

Вам, ймовірно, на зовсім зрозуміло, навіщо я розширюю клас View. Чи не служить він просто для виклику методу response.render? Що ж, на практиці є класи, в яких ви захочете відправити інший заголовок або, можливо, змінити об'єкт response якимось чином. Як, наприклад, при відправленні даних у форматі JSON:

1	var data = {"developer": "Krasimir Tsonev"};
2	response.contentType('application/json');
3	response.send(JSON.stringify(data));

Замість того щоб виконувати це кожного разу, було би чудово, якщо би мали класи JSONView та HTMLView. Або навіть клас XMLView для відправлення браузеру даних у форматі XML. Просто краще, якщо ви створюєте великий веб-сайт, обгорнути такі функціональні можливості, а не копіювати та вставляти той самий код знову та знову.

Нижче наведено опис вимог, пред'являємих до розташованого у папці /views/ Base.js:

var View = require("../views/Base");
describe("Base view", function() {
    it("create and render new view", function(next) {
        var responseMockup = {
            render: function(template, data) {
                expect(data.myProperty).toBe('value');
                expect(template).toBe('template-file');
                next();
            }
        }
        var v = new View(responseMockup, 'template-file');
        v.render({myProperty: 'value'});
    });
    it("should be extendable", function(next) {
        var v = new View();
        var OtherView = v.extend({
            render: function(data) {
                expect(data.prop).toBe('yes');
                next();
            }
        });
        var otherViewInstance = new OtherView();
        expect(otherViewInstance.render).toBeDefined();
        otherViewInstance.render({prop: 'yes'});
    });
});

Для того щоб протестувати роботу представлення, я повинен був створити імітацію об'єкта. У цьому випадку я створив об'єкт, що імітує об'єкт відповіді Express. У другій частині тесту я створив другий клас View, що наслідує функціонал від базового та використовує свій власний метод render. Нижче наведено код для класу, описуваного у файлі Base.js, розташованому у папці /views/:

module.exports = function(response, template) {
    this.response = response;
    this.template = template;
};
module.exports.prototype = {
    extend: function(properties) {
        var Child = module.exports;
        Child.prototype = module.exports.prototype;
        for(var key in properties) {
            Child.prototype[key] = properties[key];
        }
        return Child;
    },
    render: function(data) {
        if(this.response && this.template) {
            this.response.render(this.template, data);
        }
    }
}

Тепер ми мажмо три технічні характеристики к нашій папці tests, і якщо ви виконаєте команду jasmine-node ./tests, то у результаті до консолі буде виведено наступне:

1	Finished in 0.009 seconds
2	7 tests, 18 assertions, 0 failures, 0 skipped

Контролер

Пам'ятаєте маршрути та як їх було визначено?

1	app.get('/', routes.index);

Те, що йде після '/' у вищезазначеному прикладі маршруту, є власне контролером. Це просто функція ПЗ проміжного шару, що приймає request, response та next.

1	exports.index = function(req, res, next) {
2	res.render('index', { title: 'Express' });
3	};

Вище показано, як повинен виглядати ваш контролер у контексті Express. Інструмент командного рядка express(1) створює паку під назвою routes, проте у нашому випадку більш вдале ім'я – controllers, так що я змінив її назву, щоб вона відповідала вимогам потрібної нам схеми найменування.

Оскільки ми створюємо не просто крихітний додаток, то було би розумно створити базовий клас, який ми потім можемо розширювати. Якщо нам буде потрібно колись додати якийсь функціонал всім нашим контролерам, то цей базовий клас був би ідеальним місцем. Знов-таки, я напишу спочатку тест, так що давайте визначимося з тим, що нам потрібно:

клас повинен мати метод extend, який приймає об'єкт та повертає новий дочірній зразок;
дочірній зразок повинен мати метод run – стару функцію ПЗ проміжного шару;
клас повинен мати властивість name, що служить для ідентифікації контролера;
ми повинні мати можливість створити незалежні об'єкти на основі цього класу;

Що ж, всього-на-всього декілька вимог поки що, проте пізніше ми можемо додати додаткові. Тест виглядав би приблизно наступним чином:

var BaseController = require("../controllers/Base");
describe("Base controller", function() {
    it("should have a method extend which returns a child instance", function(next) {
        expect(BaseController.extend).toBeDefined();
        var child = BaseController.extend({ name: "my child controller" });
        expect(child.run).toBeDefined();
        expect(child.name).toBe("my child controller");
        next();
    });
    it("should be able to create different childs", function(next) {
        var childA = BaseController.extend({ name: "child A", customProperty: 'value' });
        var childB = BaseController.extend({ name: "child B" });
        expect(childA.name).not.toBe(childB.name);
        expect(childB.customProperty).not.toBeDefined();
        next();
    });
});

А нижче наведено реалізацію розташованого у папці /controllers/ Base.js:

var _ = require("underscore");
module.exports = {
    name: "base",
    extend: function(child) {
        return _.extend({}, this, child);
    },
    run: function(req, res, next) {

    }
}

Зрозуміло, що у кожному дочірньому класі повинен визначатися свій власний метод run з його власною логікою.

Веб-сайт FastDelivery

Що ж, ми маємо добрий набір класів для нашої архітектури, що задовольняє вимогам MVC, і ми розглянули наші недавно створені модулі з тестами. Тепер ми готові продовжити розробку сайту нашої вигаданої компанії FastDelivery. Давайте уявимо, що у сайту є дві частини: клієнтська частина та адміністративна панель. Клієнтська частина буде використовуватися для відображення записаної у базі даних інформації нашим кінцевим користувачам. Адміністративна панель буде використовуватися для керування тими даними. Давайте для початку розберемося з нашою адміністративною панеллю (панеллю керування).

Панель керування

Давайте для початку створимо простий контролер, що буде використовуватися для створення сторінки для адміністратора. Вміст файлу Admin.js, розташованого у папці /controllers/, наводиться нижче:

var BaseController = require("./Base"),
    View = require("../views/Base");
module.exports = BaseController.extend({ 
    name: "Admin",
    run: function(req, res, next) {
        var v = new View(res, 'admin');
        v.render({
            title: 'Administration',
            content: 'Welcome to the control panel'
        });
    }
});

Завдяки використанню заздалегідь написаних базових класів для наших контролерів та представлень ми можемо з легкістю створити точку входу для панелі керування. Клас View приймає ім'я файлу зразка. Згідно з кодом вище файл повинен називатися admin.hjs та повинен розташовуватися у папці /templates. Контент зразка виглядав би приблизно наступним чином:

<!DOCTYPE html>
<html>
    <head>
        <title>{{ title }}</title>
        <link rel='stylesheet' href='/stylesheets/style.css' />
    </head>
    <body>
        <div class="container">
            <h1>{{ content }}</h1>
        </div>
    </body>
</html>

(Для того щоб цей посібник залишався відносно коротким та у зручному для читання форматі, я не буду тут розглядати всі зразки представлень. Я вам дуже раджу завантажити початковий код з GitHub)

Тепер для застосування розглянутого вище контролера нам потрібно додати для нього маршрут в app.js:

var Admin = require('./controllers/Admin');
...
var attachDB = function(req, res, next) {
    req.db = db;
    next();
};
...
app.all('/admin*', attachDB, function(req, res, next) {
    Admin.run(req, res, next);
});

Зверніть увагу, що ми не пересилаємо метод Admin.run безпосередньо в якості ПЗ проміжного шару. Це так, оскільки ми хочемо зберегти вірний контекст. Якщо ми зробимо наступне

1	app.all('/admin*', Admin.run);

то ключове слово this в Admin буде вказувати на якийсь інший контекст.

Захищаємо панель керування

Кожна сторінка, шлях якої починається з /admin, повинна бути захищена. Для цього ми будемо використовувати ПЗ проміжного шару Express для реалізації сесій. За допомогою нього просто приєднується об'єкт до об'єкта запиту під назвою session. Тепер нам потрібно змінити наш контролер Admin для виконання двох додаткових завдань:

він повинен перевірити наявність властивості session; за його відсутності повинна бути передана форма для реєстрації;
він повинен прийняти відправлені у формі дані та авторизувати користувача при збігу імені користувача та паролю;

Нижче наведено невелику допоміжну функцію, яку ми можемо використовувати для виконання вищезазначених вимог:

authorize: function(req) {
    return (
        req.session && 
        req.session.fastdelivery && 
        req.session.fastdelivery === true
    ) || (
        req.body &&
        req.body.username === this.username &&
        req.body.password === this.password
    );
}

Спочатку у нас є інструкція, за допомогою якої виконується спроба розпізнавання користувача з використанням об'єкта session. Потім ми перевіряємо, чи було надіслано форму. Якщо так, то дані форми стають доступними в об'єкті request.body, значення якого встановлюється за допомогою ПЗ проміжного шару bodyParser. Потім перевіряємо, чи співпадає ім'я користувача та пароль.

А тепер переходимо до методу run контролера, в якому використовується наш новий допоміжний метод. Ми перевіряємо, чи авторизовано користувача, і в залежності від результату відображуємо або саму панель керування, або сторінку для входу в систему.

run: function(req, res, next) {
    if(this.authorize(req)) {
        req.session.fastdelivery = true;
        req.session.save(function(err) {
            var v = new View(res, 'admin');
            v.render({
                title: 'Administration',
                content: 'Welcome to the control panel'
            });
        });         
    } else {
        var v = new View(res, 'admin-login');
        v.render({
            title: 'Please login'
        });
    }       
}

Керування контентом

Як згадав на початку посібника, нам потрібно керувати багатьма частинами веб-сайту. Для полегшення процесу давайте зберігати всі дані в одній колекції. Кожний запис буде мати властивості title, text, picture та type. За допомогою властивості type буде визначатися, до якої частини додатка належить запис. Наприклад, для сторінки Contacts буде потрібен тільки один запис з type: 'contacts', тоді як для сторінки Blog буде потрібно багато записів. Що ж, нам потрібні три сторінки для додавання, редагування та відображення записів. Перед тим, як ми приступимо до створення нових зразків, додаванню стильового оформлення та нових можливостей для контролера, нам потрібно написати наш клас для моделі, що знаходиться між сервером MongoDB та нашим додатком і, звісно ж, надає зрозумілий API.

// /models/ContentModel.js

var Model = require("./Base"),
    crypto = require("crypto"),
    model = new Model();
var ContentModel = model.extend({
    insert: function(data, callback) {
        data.ID = crypto.randomBytes(20).toString('hex'); 
        this.collection().insert(data, {}, callback || function(){ });
    },
    update: function(data, callback) {
        this.collection().update({ID: data.ID}, data, {}, callback || function(){ });   
    },
    getlist: function(callback, query) {
        this.collection().find(query || {}).toArray(callback);
    },
    remove: function(ID, callback) {
        this.collection().findAndModify({ID: ID}, [], {}, {remove: true}, callback);
    }
});
module.exports = ContentModel;

За допомогою цієї моделі для кожного запису генерується унікальний ID. Він нам стане у пригоді для оновлення інформації у подальшому.

Якщо нам потрібно додати новий запис для нашої сторінки Contacts, то ми можемо просто скористатися наступним кодом:

var model = new (require("../models/ContentModel"));
model.insert({
    title: "Contacts",
    text: "...",
    type: "contacts"
});

Що ж, ми маємо API для керування даними нашої колекції mongodb. Тепер ми готові до написання коду для UI (* інтерфейс користувача), щоб скористатися цим функціоналом. Переходимо до першої частини додатка. Контролер Admin потрібно буде змінити доволі сильно. Для полегшення нашої задачі я вирішив скомбінувати список доданих записів та форму для їх додання/редагування. Як ви бачите на скриншоті нижче, ліва частина сторінки відведена для списку, а права частина – для форми.

Через те що все розташовується на одній сторінці, нам потрібно зосередитися на частині, що відповідає за створення сторінки, або, точніше, на даних, що відправляються зразку. Тому я створив декілька допоміжних функцій, які комбінуються наступним чином:

var self = this;
...
var v = new View(res, 'admin');
self.del(req, function() {
    self.form(req, res, function(formMarkup) {
        self.list(function(listMarkup) {
            v.render({
                title: 'Administration',
                content: 'Welcome to the control panel',
                list: listMarkup,
                form: formMarkup
            });
        });
    });
});

Цей код виглядає трохи страхітливо, але працює так, як нам це потрібно. Перший допоміжний метод – метод del, за допомогою якого перевіряються поточні параметри запиту за методом GET, і якщо він виявляє action=delete&id=[id of the record], то видаляє дані з колекції. Друга функція називається form та відповідає, головним чином, за відображення форми справа сторінки. За допомогою неї перевіряється, чи відправлено форму, і відповідним чином оновлюються або створюються записи у базі даних. У кінці коду метод list отримує інформацію та підготовлює HTML-таблицю, яка пізніше відправляється зразку. З реалізацією цих трьох допоміжних функцій ви можете ознайомитися у початковому коді для цього посібника.

Далі я вирішив показати вам функцію, за допомогою якої забезпечується вивантаження файлів:

handleFileUpload: function(req) {
    if(!req.files || !req.files.picture || !req.files.picture.name) {
        return req.body.currentPicture || '';
    }
    var data = fs.readFileSync(req.files.picture.path);
    var fileName = req.files.picture.name;
    var uid = crypto.randomBytes(10).toString('hex');
    var dir = __dirname + "/../public/uploads/" + uid;
    fs.mkdirSync(dir, '0777');
    fs.writeFileSync(dir + "/" + fileName, data);
    return '/uploads/' + uid + "/" + fileName;
}

Якщо файл було відправлено, то властивість .files об'єкта запиту скрипта node заповнюється даними. У нашому випадку ми маємо наступний елемент HTML:

1	<input type="file" name="picture" />

Це означає, що ми могли би отримати доступ до надісланих даних за допомогою req.files.picture. У вищевказаному фрагменті коду req.files.picture.path використовується для отримання первинних даних файлу. Пізніше ті самі дані записуються до недавно створеної папки, і в кінці коду повертається відповідний URL. Всі ці операції виконуються синхронно, проте згідно з усталеною практикою слід використовувати асинхронний варіант методів readFileSync, mkdirSync та writeFileSync.

Клієнтська частина застосування

З найскладнішим ми тепер розібралися. Адміністративна панель працює, і ми маємо клас ContentModel, який надає нам доступ до інформації, що зберігається у базі даних. Тепер нам потрібно написати контролери для клієнтської частини та прив'язати їх до зберігаємих даних.

Нижче наведено код контролера для сторінки Home, розташований у файлі Home.js (папка /controllers/):

module.exports = BaseController.extend({ 
    name: "Home",
    content: null,
    run: function(req, res, next) {
        model.setDB(req.db);
        var self = this;
        this.getContent(function() {
            var v = new View(res, 'home');
            v.render(self.content);
        })
    },
    getContent: function(callback) {
        var self = this;
        this.content = {};
        model.getlist(function(err, records) {
            ... storing data to content object
            model.getlist(function(err, records) {
                ... storing data to content object
                callback();
            }, { type: 'blog' });
        }, { type: 'home' });
    }
});

Для Домашньої сторінки потрібен один запис типу home та чотири записи типу blog. Після реалізації контролера нам всього-на-всього потрібно додати маршрут для нього в app.js:

1	app.all('/', attachDB, function(req, res, next) {
2	Home.run(req, res, next);
3	});

Знов-таки, ми додаємо об'єкт db до об'єкта запиту. Працюємо з цим контролером подібно до того, як працювали з адміністративною панеллю.

Решта сторінок для нашої клієнтської частини дуже подібна розглянутій вище тим, що для них всіх є контролер, завдяки якому витягуються потрібні дані за допомогою класу моделі, і, звичайно, створюється певний маршрут. При цьому є дві цікаві ситуації, які мені хотілося би обговорити більш детально. Перша пов'язана зі сторінкою для блога. Для цієї сторінки повинна бути можливість як відображення всіх статей, так і тільки однієї. Так що нам потрібно зареєструвати два маршрути:

app.all('/blog/:id', attachDB, function(req, res, next) {
    Blog.runArticle(req, res, next);
}); 
app.all('/blog', attachDB, function(req, res, next) {
    Blog.run(req, res, next);
});

У них обох використовується той самий контролер – Blog, проте викликаються різні методи run. Також зверніть увагу на рядок /blog/:id.. Цей маршрут буде оброблювати запити, виконувані за адресами на зразок /blog/4e3455635b4a6f6dccfaa1e50ee71f1cde75222b, і довгий фрагмент буде доступний у req.params.id. Іншими словами, ми маємо можливість визначення динамічних параметрів. У нашому випадку це ID запису. Після отримання цієї інформації ми можемо створити унікальну сторінку для кожної статті.

Другий цікавий момент полягає в тому, як я створив сторінки Services, Careers та Contacts. Зрозуміло, що вони використовують тільки один запис з бази даних. Якщо би нам потрібно було створити окремий контролер для кожної сторінки, то ми повинні були би копіювати/вставляти той самий код і просто змінювати значення поля type. Є, проте, більш вдалий спосіб досягнення цього з використанням тільки одного контролера, який приймає певне значення type та відповідний до нього метод run. Що ж, нижче наведено код для маршрутів:

app.all('/services', attachDB, function(req, res, next) {
    Page.run('services', req, res, next);
}); 
app.all('/careers', attachDB, function(req, res, next) {
    Page.run('careers', req, res, next);
}); 
app.all('/contacts', attachDB, function(req, res, next) {
    Page.run('contacts', req, res, next);
});

Ф контролер виглядав би приблизно наступним чином:

module.exports = BaseController.extend({ 
    name: "Page",
    content: null,
    run: function(type, req, res, next) {
        model.setDB(req.db);
        var self = this;
        this.getContent(type, function() {
            var v = new View(res, 'inner');
            v.render(self.content);
        });
    },
    getContent: function(type, callback) {
        var self = this;
        this.content = {}
        model.getlist(function(err, records) {
            if(records.length > 0) {
                self.content = records[0];
            }
            callback();
        }, { type: type });
    }
});

Розгортаємо застосування на сервері

Розгортання додатка, створеного на основі Express, власне, нічим не відрізняється від розгортання будь-якого іншого додатка Node.js.

Файли вивантажуються на сервер.
Процес (* набір з одного і більш трендів (потоків) і асоційованих із ними системних ресурсів) node повинен бути зупинений (якщо його запущено).
Повинно бути виконано команду npm install для встановлення нових залежностей (якщо такі є).
Головний скрипт повинен бути потім знову запущений.

Майте на увазі, що Node – досі доволі молода платформа, так що не все може працювати належним чином, проте вона постійно вдосконалюється. Наприклад, за допомогою forever гарантується, що ваша програма Node буде виконуватися постійно. Ви можете це виконати завдяки наступній команді:

1	forever start yourapp.js

Я також користуюся цим інструментом на моєму сервері. Це чудовий невеликий інструмент, який проте вирішує значну проблему. Якщо ви запускаєте ваш додаток просто завдяки команді node yourapp.js, то після раптового завершення роботи сервер перестає працювати. forever просто перезапускає застосування.

Тепер ось що: я не адміністратор, проте хотів би поділитися моїм досвідом інтегрування додатків Node з сервером Apache або Nginx, оскільки вважаю, що так чи інакше це відноситься до процесу розробки.

Як ви знаєте, Apache звичайно прослуховує підключення по 80 порту, і це означає, що якщо ви перейдете за адресою http://localhost або http://localhost:80, то побачите сторінку, відправлену сервером Apache, і, скоріше за все, скрипт вашого додатка node прослуховує підключення по іншому порту. Так що вам потрібно додати віртуальний хост, який приймає запити та відправляє їх на потрібний порт. Наприклад, давайте припустимо, що я хочу розмістити тільки-но створений мною сайт на моєму локальному сервері Apache, доступ до якого здійснюється за адресою expresscompletewebsite.dev. Для початку нам потрібно додати наш домен до файлу hosts.

1	127.0.0.1 expresscompletewebsite.dev

Далі нам потрібно відкрити файл httpd-vhosts.conf у папці, використовуваній для конфігурації Apache, та додати туди наступний код:

# expresscompletewebsite.dev
<VirtualHost *:80>
    ServerName expresscompletewebsite.dev
    ServerAlias www.expresscompletewebsite.dev
    ProxyRequests off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    <Location />
        ProxyPass http://localhost:3000/
        ProxyPassReverse http://localhost:3000/
    </Location>
</VirtualHost>

Після цього сервер як і раніше прослуховує запити по 80 порту, проте буде пересилати їх на 3000 порт, що прослуховує додаток Node.

Встановлювати на Nginx набагато легше, і, правду кажучи, це більш вдалий варіант для розміщення додатків, розроблених за допомогою платформи Node.js. Вам як і раніше потрібно додати ім'я домену у вашому файлі hosts. Після цього просто створіть новий файл у папці /sites-enabled, розташованій у папці, де встановлено Nginx. Контент файлу виглядав би приблизно наступним чином:

server {
    listen 80;
    server_name expresscompletewebsite.dev
    location / {
            proxy_pass http://127.0.0.1:3000;
            proxy_set_header Host $http_host;
    }
}

Майте на увазі, що ви не можете запустити ні Apache, ні Nginx, використовуючи вищевказані налаштування хоста. Це так, оскільки для роботи цих обох серверів потрібен порт 80. Також вам можуть знадобитися додаткові відомості для більш вдалого налаштування конфігурації сервера, якщо ви плануєте використовувати обговорювані вище фрагменти коду у середовищі для виконання остаточної версії додатка. Як я сказав раніше, я не експерт у цій області.

Завершення

Express – чудовий фреймворк, що надає вам хорошу відправну точку для створення додатків. Як ви розумієте, те, як ви його розширите та що будете використовувати при роботі з ним, залежить від вас. За допомогою нього полегшується виконання рутинних задач завдяки використанню деякого ПЗ проміжного шару, а цікава частина роботи залишається розробникові.

Початковий код

Початковий код для прикладу створеного нами у цьому посібнику сайту доступний на GitHub - https://github.com/tutsplus/build-complete-website-expressjs. За бажанням можете форкнути його та поекспериментувати з ним. Нижче перелічено кроки для запуску сайту:

Завантажте початковий код
Перейти до папки app
Виконайте команду npm install
Виконайте команду mongodb daemon
Виконайте команду node app.js