Содержание статьи
Угнаться за всеми появляющимися технологиями для создания веб-приложений невозможно. Да и незачем. Но за трендовыми решениями, которые проверены на реальных проектах гуруразработчиками, следить нужно. Мы постарались отследить самые яркие тренды — и вот что получилось.
Тренд 1. Отказ от SQL
К современным веб-проектам предъявляются колоссальные требования по части отказоустойчивости. Они должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных SQL баз данных и переход там, где это возможно, к технологиям noSQL, использующих для хранения данных простые структуры данных вроде «ключ-значение». То, что сложно было представить еще несколько лет назад, стало сейчас настолько очевидным, что многие не перестают удивляться: «Как это мы не дошли до этого ранее?». Ведь для большинства веб-приложений вовсе не нужны все эти множества типов данных, поддерживаемых СУБД, и средств их выборки.
Часто необходимо просто сохранить информацию и иметь к ней доступ с минимальной задержкой и высокой надежностью. SQL-запросы, как ни крути, даже при оптимизации выполняются относительно медленно. При этом для хранения данных зачастую вполне достаточно просто хранить ключ записи и ее значение. Значение — это обычные сериализированные данные, например, в формате JSON или более продвинутой структуре вроде messagePak, Google ProtoBuf или Apache Thrift.
MongoDB пошла еще дальше, реализовав в качестве замены для удобного JSON специальный двоичный формат. Другая разработка — Redis — перевернула понятие key-value-хранилищ, добавив к ним простые, но оказавшиеся эффективными и востребованными списки, хэши и сортированные массивы. Интерфейс доступа к noSQL-базе также максимально прост — обычно это простейшие команды типа get (получить данные по ключу), set (записать данные с ключом), delete (удаляет ключ и его данные), update (обновляет уже существующие данные). На низком уровне такие базы строятся на базе хеш-таблиц и их разновидности — распределенной хеш-таблицы (DHT).
Благодаря этому решения noSQL оказались не только очень быстрыми, но еще и легко масштабируемыми. Свойства DHT такие, что можно присоединять новые серверы постоянно, и такая база будет расти и расти. Столько, сколько надо. При этом в самих приложениях ничего менять не надо, все делается автоматически! Это очень важно, потому что если приложение не может одинаково хорошо работать и на одном, и на тысяче серверов, то оно не масштабируемо. А значит при неожиданно высокой нагрузке, оно ляжет и уже не сможет восстановить работу, даже при покупке новых серверов. В то время как обычные СУБД просто рвутся на части и подпираются костылями, чтобы работать хоть на паре десятков серверов одновременно, практически любое noSQL-решение может спокойно масштабироваться хоть на тысячу серверов. И все это на скоростях более 100 тысяч операций в секунду, над гигабайтами данных и миллионами ключей на обычном железе.
За примером далеко ходить не нужно.
Facebook использует собственноручно разработанное noSQL-решение Cassandra, а
Twitter
опирается в работе на связку Cassandra и технологии HBase для написания кода.
Тренд 2. Продвинутое использование JavaScript
Не пойми меня неправильно: конечно же, ни один серьезный веб-проект не может обойтись без большого количества JS-кода. Реализация фронтенда (т.е. интерфейса приложения) практически всегда реализуется именно с помощью этого языка, какая бы технология ни применялась для создания бэкэнда. Но! Пытливые умы почесали головы и подумали: а не будет ли легче использовать JS более универсально: и на клиенте, и на сервере? Он гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. Простой.
Но что важнее всего — его асинхронность и неблокируемость. Это важный плюс по сравнению со, скажем, обычным PHP-скриптом, который непременно блокируется во время выполнения: например, в ожидании выборки из базы данных или ответа от другого сервера. Код выполняется последовательно: пока не будет получен ответ, сценарий будет тупо простаивать. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Все строится на событиях и функциях, которые эти события обрабатывают (так называемые callback’и или обработчики событий). К такому подходу нужно привыкать, но чтобы сделать жизнь проще, были разработаны специальные фреймворки.
Одним из самых продвинутых стал проект
Node.JS (подробнее о нем ты можешь прочитать в 139 номере ][).
В основе его лежит V8, движок JavaScript, который используется в браузере Google Chrome и благодаря которому он работает невероятно быстро. Это не пустые слова. К использованию Node.JS меня подтолкнул простой эксперимент. На работе я сделал простенький HTTP-сервер (ну честно, 10 строчек кода) и попробовал его протестировать на нагрузку. В ситуации, когда уже падал наш Nginx-сервер, приложение на Node.JS спокойно продолжало принимать подключения и работать как ни в чем не бывало.
Тренд 3. Использование функциональных языков
Асинхронность — это, конечно же, конек не только JavaScript. Для Python хорошие ребята придумали фреймворки Twisted и Tornado, для Ruby есть EventMachine, для PHP — phpDeamon с честным fastcgi, для Java — Netty. Но помимо примочек для самых обычных языков программирования, все большую популярность набирают функциональные языки и платформы. Например, Erlang, который специально разработан для создания распределенных систем компанией Ericsson. Сейчас найдется немало людей, которые скажут, что Erlang рулит и прочих равных обставляет всех конкурентов, эффективно обрабатывая сотни тысяч потоков и умело занимая все доступные ядра и серверы. И не просто скажут, а приведут реальные примеры. Одна проблема: в таком коде сам черт ногу сломает, а если твой программист вдруг уйдет, то проект с большой вероятностью на некоторое время встанет. Специалистов пока очень мало.
Еще одно развивающееся направление — Scala. Это мощный, смешанный объектно-ориентированный и функциональный язык со статической типизацией и встроенной параллельностью. Шутка ли, Twitter, наконец, слез с Ruby-иглы и переписал большую часть критичного кода на Scala! Это что-то да означает. Scala часто используется в связке с платформой Akka, для которой не чужды понятия «многопоточность», «устойчивость к сбоям», «распределенная архитектура», «реалтайм». Фреймворк основан на распараллеливании вычислений в виде акторов (небольшие блоки кода, которые самостоятельно планируются для исполнения по разным ядрам, процессам и даже узлам кластера). Функциональные языки активно используются в тех проектах, где пользователю нужна работа в реальном времени.
Тренд 4. Реалтайм для веба
Да-да, для многих веб-приложений стало крайне важным работать в режиме реального времени, с минимально возможными задержками. Задача, которая непросто решается даже для нескольких пользователей, становится огромной проблемой, когда счет юзеров идет на сотни тысяч. Сейчас уже есть немало решений, позволяющих реализовать реалтайм для веба (мы рассказывали про технологию Comet), но самой прогрессивной и многообещающей технологией являются так называемые веб-сокеты. Все уже устали, что в браузере у тебя есть только HTTP и ничего больше, да и тот урезанный и затиснутый в ограничения безопасности.
Конечно, вражеский Flash заботливо подсуетился и предложил альтернативу, но кому он теперь нужен? Реализовать реалтайм на основе привычного HTTP очень сложно: на каждый чих ему нужно создавать новое соединение, снова и снова гоняя хотя бы пару килобайт данных туда-сюда и ожидая в среднем полсекунды. На деле имеем не реалтайм, а скорее костыли. Создатели десктопных приложений потирают руки: у них-то есть полный доступ к системе и возможность использовать сеть напрямую на низком уровне. Но в HTML5 (уже даже не хочется лишний раз его упоминать) появится расширение WebSockets, которое реализует те же самые сокеты, но в браузере.
Сокеты для любого веб-приложения — как тебе? Раз соединившись с сервером, ты можешь держать открытым канал передачи (в обе стороны) сколько угодно долго и пересылать по нему любые данные.
Без задержек и лишних тормозов — все ограничивается лишь каналом связи. Как только у сервера появятся новые данные для тебя, ты сразу их получишь. И наоборот. Увы, до полноценной реализации этой технологии еще далеко. Многие разработчики кинулись создавать различные проекты, вешая на них ярлык реалтайма. Но вот в чем проблема: подходящего сервера до сих пор нет! Любимый Nginx, хоть и добравшийся уже до версии 1.0.3, увы, никак не умеет работать с сокетами. Просто все существующие веб-сервера пока не умеют корректно работать в ситуации, когда клиенты не просто пришли, сделали запрос и отвалились до следующего сеанса связи (пусть даже раз в секунду, по меркам сервера это очень много времени), а постоянно висят на связи. Вот тут-то и пригодился новомодный JavaScript на стороне сервера. Благодаря Node.JS подходящий сервер подчас можно написать за вечер. При этом он будет держать столько постоянно открытых соединений, сколько позволят тебе ресурсы сервера (размер памяти и настройки ядра ОС и сетевого стека).
Тренд 5. Развертываемость и расширяемость
Раз уж мы вспомнили про аппаратные ресурсы, то самое время поговорить, пожалуй, про самый главный тренд не только в разработке, но и вообще во всей IT-отрасли — облачные технологии. То, насколько cloud-сервисы упростили жизнь при создании сложных проектов сложно переоценить. Простой пример — всем известный сервис Dropbox. Разработки не стали изобретать велосипед с разработкой технологии для хранения данных, а использовали облачный сервис для хранения данных Amazon S3. Тут все просто.
Сколько надо места для файлов — столько у тебя и будет. Какая будет нагрузка — такую сервис и выдержит. Только за каждый гигабайт хранилища и трафик нужно заплатить. С серверами все аналогично.
Нужен только один — пожалуйста. Нужен кластер из 16 сервераков сразу — нет проблем. Если вдруг нагрузка на приложение увеличилась и нужно масштабировать систему, то это можно сделать буквально за несколько минут. Такую услугу, в частности, предлагает все та же компания Amazon (по сути, это настоящий лидер отрасли), предоставляя технологию EC2. Впрочем, многим вообще не нужны никакие серверы — им важна готовая инфраструктура для развертывания своих разработок из «коробки». Хостинг платформы (Platform as a Service или PaaS) — то, что сейчас набирает все большую и большую популярность. Это неудивительно. Добрые дяди за тебя уже поставили и настроили все, что может пригодиться для твоего приложения. Взяли несколько языков, типа PHP, Ruby вместе с Rails, обязательный Python и выскочку Node.JS, прицепили традиционную базу данных MySQL, а чтобы эстеты замолчали, добавили немного перчинки в виде NoSQL — MongoDB, Redis или Riak. Поверх поставили memcached, а вместо анахронизма в виде FTP — теперь предлагают юзать распределенную систему управления версий Git. Все это управляется через красивый веб-интерфейс, в котором можно просто сказать: «Хочу пять серверов memcached, два РНР и еще базу данных заверните». Тебе тут же выдают ключи доступа и пароли — и все, можно действовать. Команды «git clone && git push» — и вот твое приложение уже вольготно себя чувствует на серверах, а ты даже не подозреваешь, на чем и где оно крутится.
Помимо этого разработчикам предлагается специальный API, чтобы программа могла сама себе выделять ресурсы, например, добавляя еще одну базу данных или новый инстанс приложения. Среди автоматизированных cloud-платформ можно выделить: AppEngine, PHPFog, Azure, RackCloud.
Тренд 6. Социализация разработчиков
Я не зря в предыдущем разделе упомянул Git. Постоянно общаясь в среде разработчиков, не перестаю замечать, как FTP и SVN стремительно теряют популярность. Все потихоньку переходит на Git. Поправил файлик, добавил немного гениального кода и хочешь его выкатить на хостинг? Сначала закоммить его в Git-репозиторий, напиши комментарий, что хорошего ты там накодил, а потом только разверни на сервере, причем при помощи все того же Git’а. И ведь действительно удобно: и разработка, и деплой идет при помощи одной системы. Все в командной строке.
Посмотрев на популярность сервиса Github (github.com), многие провайдеры, чтобы привлечь разработчиков и облегчить им жизнь, стали разворачивать у себя Git-репозитории как единственную возможность что-то залить на сервер. Ну, теперь хоть не будет криков, что снова Вася не то залил на сервер и все перестало работать. Впрочем, используемый инструмент — это всего лишь частность. Сам подход к разработке кода немного поменялся. Если раньше все твои друзья сидели уютно и втихаря что-то там программировали, то теперь большинство перебралось на сервисы вроде GitHub’а и занимаются «социальным кодингом». С приходом Git’а стало намного проще следить за прогрессом твоих любимых библиотек. Если что-то надо срочно поправить в чужом коде, так без проблем: кнопка «форк» теперь так же близко, как и кнопка для создания тикета. А чтобы автор заморского чуда принял твои правки, не нужно долго на ломаном английском объяснять, что ты сделал конфетку из его непонятного кода.
Просто отправь ему специальную заявку (пулл-реквест), и если все хорошо, твой код быстро попадает в основную ветку. Github стал настоящим прорывом, потому что собрал в очень удобном веб-интерфейсе все, что надо матерому гику-программисту. И что еще важно — он добавил острое блюдо социальщины. Теперь не нужны все эти твиттеры и фейсбуки: для многих разработчиков (прежде всего Opensource) Github стал местом жизни, общения и тут же, не отходя от кассы, кодинга. А все потому, что выстраивая среду для совместной разработки кода, Github не прячет людей за всеми этими коммитами и чекаутами, а активно их выталкивает на поверхность. Согласись, очень приятно видеть свою аватарку или фотку возле каждого принятого патча в важный проект. Не могу не упомянуть и про новые среды разработки, реализованные в браузере. Например, систему Cloud9 (c9.io), которая изящно дополняет GitHub и позволяет реально вести разработку с любого места, где есть интернет.
Тренд 7. Мобильные платформы
Последний тренд в нашем материале диктует само время. Вебсервисы все чаще используются с мобильных устройств. Портативные девайсы методично захватывают мир, поделив его между «яблочниками» и «роботами». А вот дизайнерам и разработчикам приходится поддерживать оба лагеря. К счастью, сегодня почти все топовые JS-фреймворки имеют мобильные версии (часто совместимые по API с обычными вариациями), что позволяет просто заменой файла подогнать сайт под требования мобилок.
Самым ожидаемым является jQuery Mobile (сейчас доступна только alpha-версия), который по заявлениям будет работать на всех мыслимых и немыслимых платформах, включая экзотику для нас, типа Blackberry, Windows Phone, webOS, bada и другие. Будучи расширением, а по большому счету, очень крутым плагином для jQuery, он стандартизирует API для различных устройств и их браузеров. К слову, в мобильном мире браузеры — это вообще один большой кошмар, так что браузерные войны на десктопах это только цветочки. Помимо этого разработчикам предлагаются строгие правила по созданию интерфейсов, чтобы веб-приложения имели понятный стандартизированный набор элементов интерфейса, а пользователь не искал на своем маленьком экране полминуты кнопки «назад» или «отмена».
Облачные интерфейсы на заметку
Если ты хочешь использовать возможности облачных сервисов им надо в своих проектах, советую тебе воспользоваться некоторыми полезными вспомогательными инструментами.
- Apache Nuvem (incubator.apache.org/nuvem) — попытка создать кроссплатформенный открытый интерфейс для работы с разными cloud-платформами, включая Amazon EC2, Microsoft Azure и Google AppEngine. В идеале, твоя программа сможет использовать ресурсы сразу нескольких облаков.
- Deltacloud (incubator.apache.org/deltacloud) — решение на Ruby, умеющее работать со всеми известными (и не очень) cloudпровайдерами. Предоставляет единый REST-интерфейс, который скрывает нюансы разных платформ.
- libcloud (libcloud.apache.org) — библиотека для программ на Java или Python, которая взаимодействует реально чуть ли не со всеми в мире известными облачными платформами и унифицирует основные операции по созданию и управлению виртуальными машинами.
- Simplecloud (simplecloudapi.org) — если ты все еще программируешь на РНР, то для тебя есть отличный компонент Zend_Cloud, который добавляет базовую поддержку хранилищ данных, очередей сообщений и другие фишки разных cloudплатформ просто в твое веб-приложение на Zend Framework или даже на чистом РНР.
