Такое громкое название говорит о том, что сегодня мы будет сравнивать концепцию 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
