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