Автор оригинала: Arun Ravindran.
Говоря о Django на PyCon India в этом году, я чаще всего задавался вопросом, поддерживает ли он одностраничные приложения или архитектуру, управляемую событиями. Я сразу заметил, что такие приложения реального времени обычно обрабатываются отдельными службами на бэкэнде (выполняются на другом порту?) И фреймворком JavaScript MVC спереди. Иногда Django поддерживается библиотекой REST, например Django REST или Piston также используется в качестве бэкэнда.
Но чем больше я думал об этом, тем важнее становились эти вопросы. Затем у меня была возможность прочитать о Meteor . Я попробовал некоторые из их руководств, и они были фантастическими. Я был настолько впечатлен в тот момент, что почувствовал, что этот фреймворк может существенно изменить веб-разработку. У меня даже возникло соблазн написать статью, похожую на Почему Meteor убьет Ruby on Rails для Django. Но затем разум возобладал, и я стал копать глубже.
Поэтому я написал этот пост, чтобы по-настоящему понять феномен веб-приложений в реальном времени и сосредоточить свои мысли на этом. В нем будет рассмотрено, как традиционный веб-фреймворк, такой как Django, может справиться с этим и действительно ли это возможно. Это ни в коем случае не исчерпывающий анализ, но некоторые из моих мыслей по этому поводу.
Что такое приложение реального времени?
Веб-приложения реального времени – это то, что раньше называлось приложениями AJAX или Одностраничные приложения . Кроме того, теперь мы уже не говорим о простой отправке формы без обновления. При возникновении события сервер должен отправлять данные в браузер, обеспечивая двустороннюю связь (тем самым делая термины «Сервер» и «Клиент» спорными). Для толпы Facebook это означает, что приложение может уведомлять их о событиях, например, о том, что вашим друзьям нравится ваш пост или о начале нового чата в прямом эфире – по мере того, как это происходит.
Приложение создаст впечатление, что оно «живое», в том смысле, что традиционные веб-сайты стали в значительной степени устаревшими после загрузки страницы. Чтобы использовать аналогию, традиционные веб-сайты похожи на приготовленную пищу, которая портится со временем, но веб-сайты в реальном времени похожи на живые, дышащие организмы, постоянно взаимодействующие с окружающей средой и реагирующие на нее. Как мы увидим, у обоих есть свои преимущества и цели.
Само слово «реальное время» происходит из области вычислений в реальном времени . Существуют различные формы вычислений в реальном времени в зависимости от того, насколько строго система воспринимает время отклика. Веб-приложения реального времени, вероятно, наименее строгие и могут быть названы «мягким реальным временем».
Каким сайтам они нужны?
Практически любой веб-сайт может получать обновления в режиме реального времени. Внезапно я привожу несколько примеров:
- Сайт электронной коммерции: предложения по товару, обновленная цена со скидкой в реальном времени, отзывы пользователей
- Новостной сайт: поминутное обновление новой статьи, опечатки в статье, реакции читателей, опросы
- Инвестиционный сайт: цены на акции, обменные курсы, любые инвестиционные триггеры, установленные пользователем/консультантом по клиентам.
- Сайт коммунальных служб: обновляет информацию об использовании коммунальных услуг в режиме реального времени, уведомляет о предстоящих простоях
- Микроблоггинг: практически все
Конечно, есть несколько видов сайтов, которые не подходят для лечения в реальном времени. Сайты с относительно статичным контентом, такие как блоги или вики. Представьте, что сайт блога был разработан для постоянного опроса обновлений сообщений и внезапно стал вирусным. Это расширяет пределы масштабируемости сервера для практически неизменного контента. Наиболее оптимальным подходом сегодня было бы предварительное вычисление и кэширование содержимого статьи, а также предоставление комментариев через Disqus для создания практически полного взаимодействия в реальном времени. Но, как мы вскоре увидим, это может измениться в будущем, поскольку фундаментальная природа Интернета изменится.
Веб-сайты превращаются в многопользовательские игры
В общих чертах, в наших примерах есть два вида обновлений в реальном времени – от самого сервера и от одноранговых узлов. Первый включает в себя уведомления, такие как изменение цены со скидкой, или внешние события, такие как изменение цены акций. Но одноранговые обновления от других пользователей становятся чрезвычайно ценными, поскольку пользовательский контент становится основой для многих современных сайтов. Специально для постоянного притока информации, которая сохраняет такие сайты свежими и интересными. Кроме того, социальный фактор усиливает врожденные человеческие склонности к объединению в группы, познанию и взаимодействию друг с другом.
Во многом именно так работает многопользовательская игра. Есть глобальные события, такие как изменение погоды или внезапное бедствие, и есть события, генерируемые игроками, такие как рукопашная атака или разговор в чате. Игры – одни из первых написанных мною программ; Я очень их люблю и знаю немного о том, как они работают. Веб-приложения реального времени разработаны как многопользовательские игры, особенно те, которые были разработаны для работы с центральным сервером, а не, скажем, через локальную сеть. Многопользовательские игры существуют уже около трех десятилетий, поэтому веб-приложения в реальном времени могут использовать большую часть работы, которая была затрачена на их создание.
Технически тоже есть несколько общих черт. Цикл событий, который каждый игровой программист пишет, когда начинает писать игру, лежит в основе большинства управляемых событиями серверов, таких как Node.js или Tornado. Обычно игровой клиент и сервер написаны на двух разных языках, например Eve Online с использованием Stackless Python на сервере и, возможно, C ++ со сценарием Python на стороне клиента. Это связано с тем, что, как и веб-приложения, серверная сторона должна взаимодействовать с базой данных для бухгалтерских целей и будет больше связана с вводом-выводом, чем с процессором/графическим процессором. Таким образом, потребности разные, а игры являются чрезвычайно требовательными к производительности творениями, разработчики часто используют лучший язык, инструмент или фреймворк для клиентской и серверной сторон. Часто они оказываются разными.
Конечно, в случае веб-приложений языком де-факто был JavaScript. За прошедшие годы появилось несколько API-интерфейсов JavaScript, раскрывающих базовую систему, что еще больше укрепило позицию JavaScript как предпочтительного языка на стороне клиента. Однако с несколькими языками, ориентированными на JavaScript, и с браузерами, поддерживающими исходные карты, теперь появились другие варианты, такие как pyjs и ClojureScript.
Как Метеор решает это?
Meteor и Derby утверждают, что являются новым поколением фреймворки веб-приложений, которые созданы для нужд сети реального времени. Эти фреймворки написаны на JavaScript, чтобы исключить необходимость дублирования логики на клиенте и сервере. При использовании Django или Rails объявления и поведение модели должны были быть написаны на Python/Rails на стороне сервера и, как правило, переписаны на JavaScript для фреймворков MVC, таких как AngularJS или Knockout, на стороне клиента. В зависимости от количества логики, разделяемой между клиентом и сервером, это может стать кошмаром для разработки и обслуживания.
Эти новые платформы также позволяют автоматическую синхронизацию данных. Другими словами, часть или вся информация сервера реплицируется между сервером и всеми подключенными клиентами. Если вы когда-либо программировали многопользовательскую игру, вы бы понимали, насколько сложно поддерживать согласованное состояние для всех клиентов. За счет автоматической синхронизации информации базы данных вы получаете чрезвычайно мощную абстракцию для быстрого создания веб-приложений в реальном времени.
Понимание высокого уровня того, как работают веб-фреймворки в реальном времени
Однако, как указал Дрю (создатель Dropbox), рассмотрение чего-либо в сети как локально доступного – это “утечка абстракция »из-за сетевых задержек. Программисты, скорее всего, недооценивают различные проблемы, которые могут возникать в сетях, такие как более медленное мобильное соединение или даже сбой сервера. Пользователи ненавидят, когда компонент реального времени перестает работать. Фактически, как только они начинают видеть «Соединение потеряно» в простом окне чата, худшее, что может случиться, – это то, что они теряют ход своих мыслей. Но когда весь сайт перестает отвечать на запросы, я думаю, они перестанут доверять самому сайту. Возможно, критично не полагаться полностью на механизм синхронизации данных для всех видов функциональности.
Что касается преимуществ использования одного и того же языка для обмена логикой между клиентом и сервером, на ум приходит предыдущее обсуждение многопользовательских игр. Часто требования веб-сервера сильно отличаются от требований клиента. Даже если вы избежите ада обратного вызова с Futures, JavaScript может оказаться не лучшим выбором для программирования на стороне сервера. До недавнего времени не имело значения, какой язык вы использовали на сервере, если он возвращал ожидаемые результаты, например HTML, XML или JSON. Люди могут очень привязываться к своему любимому языку, и это неудивительно; учитывая большое количество времени, которое нужно потратить на освоение каждого укромного уголка языка программирования. Ожидать, что все примут JavaScript, может быть невозможно.
Разумеется, выгода состоит в том, что общие структуры данных и логика уменьшают необходимость их дважды писать на двух разных языках. В отличие от многопользовательских игр, это большое дело в веб-программировании из-за огромного количества совместной бухгалтерии, выполняемой на обоих концах. Однако является ли использование JavaScript на обоих концах единственным выходом? Мы можем придумать хотя бы один возможный альтернативный подход. Но перед этим нам нужно посмотреть, сможем ли мы продолжить использование традиционных фреймворков.
Может ли Django адаптироваться?
Интернет в реальном времени – это реальная проблема, с которой сталкивается Django. Есть несколько элегантных решений, например запуск Django с Gevent . Но эти решения выглядят как взломы перед таким комплексным решением, как Meteor.
Сообщество Django прекрасно об этом знает. На прошлогодней конференции DjangoCon в США обычное лейтмотив «Почему я ненавижу Django» было сделано Джеффом Шмидтом, главным разработчиком Метеор. Он начинает с зловещей заметки, сравнивая появление приложений реального времени как возможное событие исчезновения Django, подобное удару астериода, который чуть не привел динозавров к вымиранию. На самом деле Джефф – большой поклонник Django, и он пытался адаптировать его к своим потребностям, но был не совсем доволен результатами.
И он не одинок. Гвидо в своем основных вопросах и ответах по Pycon упомянул, насколько сложно для традиционных веб-фреймворков, таких как Django, полностью адаптироваться к модели, управляемой событиями. Он считает, что новые фреймворки могут лучше решить эту проблему.
Прежде чем мы ответим на вопрос, может ли Django адаптироваться, нам нужно выяснить, в чем заключаются недостатки Django. Или, скорее, какие части фреймворка начинают показывать свой возраст в новой парадигме реального времени.
Точнее, HTML-шаблоны используются все реже и реже. Просто пришлите мне мясо – кажется, мантра приложений реального времени. Контент часто отображается на стороне клиента, поэтому провод по существу передает данные в форме XML или JSON. Первоначально, когда был создан Django, все клиенты не могли поддерживать рендеринг на стороне клиента с использованием JavaScript. Но с появлением все более мощных мобильных клиентов ситуация быстро меняется.
Однако это не означает, что создание шаблонов во фреймворках больше не потребуется. Можно было бы рассмотреть шаблоны XML или JSON. Но структуры данных Python можно напрямую сопоставить с JSON и обратно (как в JavaScript).
Однако ранее упомянутые решения Django, такие как Piston и Django REST, не поощряют использование сериализованных структур данных Python напрямую по уважительной причине – безопасность. Данным из внешнего мира нельзя доверять. Вам нужно будет определить классы с соответствующими типами данных для выполнения проверки базового типа. По сути, вы можете в конечном итоге повторить определения классов модели, которые вы уже написали для внешнего интерфейса.
Если вы внимательно прочтете приведенные выше примеры, вы заметите, что Интернет в реальном времени лучше всего работает для сайтов, содержащих короткие пакеты данных. Для сайтов с длинным содержанием, таких как блоги, вики или даже новостные сайты, вероятно, лучше всего придерживаться традиционных веб-фреймворков или даже статического контента. Даже если у вас соединение с очень высокой пропускной способностью, было бы просто слишком много болтать, чтобы проверять опубликованную информацию (если вы не ожидаете слишком много опечаток)
Фактически, Интернет особенно подходит для распространения длинного контента. Он лучше всего подходит для механизма запроса-ответа для поиска документов (или гипертекста, если вы хотите быть педантичным). Он не имеет состояния, поэтому по возможности подходит для кэширования. Фактически, это объясняет, почему необходимо было создать хаки, такие как длинный опрос, чтобы браузер поддерживал двунаправленную связь до появления веб-сокетов.
Это объясняет структуру WSGI, синхронного протокола для обработки запросов и ответов. Он может обрабатывать только один запрос за раз и поэтому не идеально подходит для создания приложений реального времени. Поскольку Django разработан для развертывания на сервере с интерфейсом WSGI, это означает, что асинхронный код должен обходить этот механизм.
Это кажется настоящим недостатком Django. Для решения этой проблемы могут быть полезны приемы, например частые опросы и т. Д. Но было бы намного лучше, если бы фреймворк мог интегрироваться с асинхронной моделью.
Сегодня написание API на основе REST с использованием Django и взаимодействие с ним с помощью библиотеки JavaScript MVC кажется популярным способом создания одностраничного приложения. Чтобы сделать это в реальном времени, вам, возможно, придется возиться с Gevent или Tornado и веб-сокетами.
На проблему несоответствия языкового импеданса можно взглянуть и по-другому. Почему бы не запустить ваш любимый язык, даже если это не JavaScript, на сервере и на клиенте? Поскольку JavaScript все чаще используется в качестве целевого языка (я воздерживаюсь от называть его «языком веб-ассемблера»), почему бы не преобразовать клиентскую часть кода, скажем, на Python, в JavaScript?
Если у нас может быть интеллектуальный компилятор Python, который может определять целевые байтовые коды для серверной части и общего кода; а затем нацелить JavaScript (возможно, также в asm.js для повышения производительности) и общий код для клиентской части – тогда это может просто работать. Также необходимо проработать другие детали, такие как циклы событий на обоих концах, которые могут передавать сообщения асинхронно, синхронизацию данных через компактный двоичный формат и проверку данных. Это проект, намного больший, чем написание библиотеки, но он может быть достойным решением, достаточно общим для применения на большинстве языков.
Вывод
Сегодня Django – хорошее решение для подавляющего большинства веб-приложений. Но ожидания быстро меняются, чтобы показывать обновления в реальном времени. Веб-приложениям реального времени необходимо внести множество изменений в дизайн существующих веб-фреймворков, таких как Django. Существующие решения требуют множества компонентов, а иногда и повторяющегося кода. Новые фреймворки, такие как Meteor и Derby, похоже, хорошо подходят для этих нужд и быстрого развития. Но дизайн и масштабируемость приложения реального времени по-прежнему остаются сложными. Наконец, если вы не являетесь разработчиком JavaScript, надежда еще есть.