Angular vs Derby. Повинен залишитися тільки один

Така гучна назва говорить про те, що сьогодні ми буде порівнювати концепцію MVC на клієнті (Angular, Ember, Backbone, Marionette, Knockout і т. п. тищі їх) з концепцією Full-Stack (Derby, Meteor). Розберемо плюси, мінуси, міфи, омани.

Історія питання

Давним давно, коли MVC тільки починав популяризуватися в головах веб-розробників, він був на сервері. Django, Ruby on Rails, Asp Net MVC, Yii - це приклади чудових MVC на сервері. Кожен вибирав собі мову до смаку, статичні сторінки літали по проводах, jQuery - ех, чудовий був час. Грім грянув раптово. Виявилося, що користувачі не хочуть чекати після кожного кліка, поки перезавантажиться вся сторінка, а хочуть щоб робота у вебе була більше схожа на роботу зі звичайними програмами - інтерактивна. На перший погляд jQuery + Ajax могли вирішити цю проблему, але як тільки веб-розробники стали потопати в не структурованому коді в браузері, стало зрозуміло що потрібні більш кардинальні зміни.

Ідея була в тому, що якщо MVC вже успішно структурував код на сервері, то він зможе вирішити цю проблему і на клієнті. Першим за справжнім популярним MVC на клієнті став Backbone, що представляє з себе дуже елегантне і просте рішення. Далі кожен намагався створити фреймворк своєї мрії і світ побачив Angular, Knockout, Batman, Ember і безліч інших подібних фреймворків. З'явилися цілі проекти, що допомагають не розгубитися в цьому достатку. Роутер, темплейти, бекенд, REST-api, дані по проводах - це все символи цієї радісної епохи. Здавалося щастя буде тривати вічно і ні що не зможе затьмарити безхмарне майбутнє.

Проблеми

Першими хто зіткнувся з проблемами були Twitter. Взагалі вони пройшли весь шлях. Починали з Ruby on Rails і генерації html на сервері, потім переписали все на MVC на клієнті і в якийсь момент зрозуміли, що користувач чекає 4 секунди, щоб прочитати 140 символів тексту. Зараз вони генерують частину html на сервері за допомогою Scala, а частину на клієнті за допомогою JavaScript. Google робить подібне, вони генерує html на сервері за допомогою C++, а на клієнті за допомогою JavaScript. Таку архітектуру складно підтримувати і вона не доступна для маленьких компаній і стартапів.

Пошукові системи більше люблять отримувати з сервера html, ніж Javascript. Проблему іноді намагаються вирішити генерацією html на сервері спеціально для пошуковиків в добавок до MVC на клієнті для користувачів. Інші відмовляються від MVC на клієнті на користь MVC на сервері, жертвуючи інтерактивністю заради SEO.

В епоху інтерактивності користувачі хочуть бачити у себе в браузері зміни даних, зроблені іншими користувачами негайно. Синхронізація даних між клієнтами - завдання не тривіальне, вимагає серверної частини і не може бути вирішена в категоріях MVC на клієнті.

Змінний бекенд

Одним з головних аргументів за MVC на клієнті є можливість легкої зміни бекенду. Зміна бекенду - не зовсім легка процедура, тому що MVC на клієнті передбачає, що на сервері є як мінімум REST-api, валідація, робота з даними, авторизація. У реальному житті бекенд практично ніколи не змінюється.

Можливість зміни бекенду також обмежує нас у тому плані, що ми заздалегідь відмовляємося від переваг використання однієї мови на сервері і клієнті:

- одна мова, одне середовище, одні терміни

- одні й ті самі модулі (browserify)

- повторюваність коду

Фреймворк може використовувати все це, тільки якщо у нього бекендом буде Node.js.

Node.js

Головний міф з приводу Node.js - це те, що він не стабільний і запити іноді губляться. З появою cluster і domain це більше не актуально.

Інший міф - Node.js повільний. Тут можна було б сказати що v8 всього в 3-5 разів повільніше Сі або про те, що Node.js витрачає всього близько 8 кб пам'яті на підтримку з'єднання. Але, можливо, мільйон одночасних з'єднань на одному сервері буде достатнім аргументом.

Третій міф - це неминучий Callback Hell. Ассинхронність Node.js - це його ідеологія і дає йому унікальну перевагу: нового запиту не потрібно чекати поки опрацюються всі запити до нього. Писати код в асинхронному середовищі не зовсім те саме, що в синхронному, це вимагає звички. У вмілих руках Node.js код - красивий і прозорий.

Четвертий міф - це те, що JavaScript є не дуже хорошою мовою. Дуглас Крокфорд дозволив собі не погодитися з цим твердженням.

Full-Stack

Головним міфом з приводу Full-Stack фреймворків є те, що вони представляють з себе монолітну конструкцію і позбавляють нас гнучкості у виборі конкретних компонент. Тут є протиріччя між гнучкістю і зручністю використання. І правильним рішенням буде шукати золоту середину. Наприклад, Derby складається з компонент: express.js, racer, share.js, live-db, tracks и др. Кожна з них виконує суворо свою функцію, деякі можна замінити.

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

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

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

Full-Stack фреймворки поєднують в собі все найкраще MVC на сервері і MVC на клієнті, множачи це на переваги використання однієї мови, що в купе з унікальними функціями, такими як вбудована синхронізація даних, дає в руки веб-розробника потужний інструмент для реалізації його ідей, раніше доступний тільки таким монстрам як Google і Twitter, і приближає вже наближає його ідей.

Матеріали по Derby