Node.js и новый фронтенд в вебе

Original author: Nicholas C. Zakas
  • Translation
(Дата оригинала — 7.10.2013. У оригинала — очень оживлённая дискуссия в комментариях)

Фронтенд-разработчики имеют довольно долгую и сложную историю в программировании. Долгое время отправляемое в браузер было так легко отобразить, что не было настоящей потребности в этой специализации. Многие считали, что они были просто графическими дизайнерами с немного другими выразительными средствами. Мысль о том, что они могли в один прекрасный день специализироваться в веб-технологиях, HTML, CSS, Javascript — была смехотворной; в лучшем случае — пользовательский интерфейс их удел или, в конце концов, кто-то мог специализироваться на том и другом и иметь эту работу.

Джаваскрипт был технологией, которая начала менять представление о фронтендщиках, преобразуя их в инженеров интерфейса. Этот забавный игрушечный язык, от которого серьёзные программисты воротили носы, стал движущей силой Интернета. По мере появления новых браузеров, CSS и HTML создавали кроссбраузерные несовместимости, которые довольно ясно определяли необходимость во фронтенд-разработчиках. Сегодня фронтенд-специалисты — наиболее востребованные кандидаты на вакансии в мире.

Два уровня пользовательского интерфейса


Даже после начала ажиотажа с Ajax, работа разработчика интерфейсов ассоциировалась в первую очередь с технологиями в браузере. HTML, CSS и Javascript были главными приоритетами, в которых веб-сервер был нужен лишь для того, чтобы убедиться, что на фронтенд всё выводится надлежащим образом. В некотором смысле, было два интерфейса — один в браузере, и другой — на сервере, который генерировал нужные данные для браузера. Было очень мало контроля над серверным слоем интерфейса, чаще всего построенного бекендщиками, которые редко понимали потребности «инженеров переднего конца».

В этой архитектуре слой интерфейса в браузере был единственной областью работы фронтендщиков. Интерфейс бекенда, где встречались интересы фронтендщиков и бекендщиков, были внутренностями серверного приложения. Там вы найдёте кеширование, аутентификацию и остальные критически важные части приложения. Бекенд-интерфейс, часто в виде шаблонов, был тонким слоем серверного приложения для связи с исполнением бизнес-логики.

Таким образом, фронтендом был браузер, а всё остальное было бекендом, несмотря на наличие контакта на уровне фонового интерфейса. В основном, так было до недавнего времени.

Внедрение nodeJS


При первом появлении nodeJS породил волну энтузиазма среди фронтендщиков, равной которой не было со времён появления термина «AJAX». Идея написания JavaScript на сервере в качестве цели — было значительнейшим освобождением. Больше не нужно было выкарабкиваться из PHP, Ruby, Java, Scala, или любого другого языка в дополнение к работе на фронтенде. Если сервер может быть написан на Javascript, то наше полное знание ограничено HTML, CSS, JavaScript для получения полного приложения. Он сулил такие перспективы, и это было очень интересно.

Я никогда не был поклонником PHP, но должен был использовать его в работе на Yahoo. Я жаловался на время, когда приходилось заниматься отладкой, и на глупые причуды языка, с которыми было проще стрелять себе в ногу, чем должно было быть. После 6 лет Java-сервера я пересел в корыто на PHP. Я верил и продолжаю верить в то, что статически типизированные языки — именно то, что хотелось бы видеть во внутренностях бизнес-логики. Несмотря на то, насколько я люблю Javaccript, есть вещи, которые я не хочу видеть написанными на Javascript — корзина для покупок в интернет-магазине, например.

На мой взгляд, nodeJS никогда не заменит всё на сервере с Javascript. Его восхитительные механизмы и расширение прав и возможностей не делает его единственно правильным выбором. Нет, что касается меня, я совсем другое имею в виду: освобождение серверного UI от остальной серверной части.

С переходом многих компаний на сервисно-ориентированное проектирование и REST, есть возможность выделить бекенд интерфейса на отдельном сервере. Если все бизнес-запросы выполняются через REST, то всё, что нужно — уметь общаться через REST. Бекенд-инженеры заботятся о переходах со страницы на страницу? Об одностраничности или о полном обновлении страниц? О том, работает на клиенте jQuery или YUI? как правило, не всегда. Они заботятся главным образом о хранении, обработке и безопасном и безошибочном использовании данных.


И тут nodeJS даёт фронтендщикам много возможностей. Бэкеры могут написать REST-запросы на любом языке. Мы, интерфейсники, можем использовать nodeJS для работы с серверным уровнем на чистом JS, выполняя необходимые функции через REST-запросы. Теперь имеется чёткое разделение ответственностей. Фронтенд сейчас расширился на сервер, до границ UI на nodeJS, а остальная часть задач остаётся бекендерам.

Нет! Страшно!


Это посягательство интерфейсников на родовые угодья наводит ужас на рыцарей «заднего конца», многие из которых всё ещё питают иллюзии о JS как об игрушечном языке. По моему опыту — именно они вызывают разногласия по поводу принятия или непринятия nodeJs в проект. Бекенд — это спорная территория между двумя типами инженеров. Я не вижу никаких иных оснований, чем желание оставить «всё, как было». Как только вы получите сервер — получите ответственность бекендщиков. Простои и ясно, что это — борьба за сферы влияния.

Всё же, так быть не должно. Разделение бекенд-UI и бекенд-бизнес-логики имеет смысл только в больших системах. Зачем фронтендщикам забота о выполнении критических бизнес-функциях на серверном языке? Зачем бизнес-функциям попадать в бекенд-UI? Потребности интерфейсников принципиально отличаются от потребностей бекенда. Если вы следуете архитектурным подходам, таким как принцип единственной ответственности, разделение интересов и модульность, то кажется почти глупым, что до сих пор у вас не было такого разделения.

Кроме того, nodeJS прежде не существовало. Не лучший вариант для фронтендщиков — создавать бекенд-UI на своём собственном языке. Если вы писали на PHP, почему бы не писать на нём шаблоны для фронтенда? Если вы писали на Джаве, почему бы не использовать JSP? Не было никакого лучшего выбора для фронтендеров, чтобы нехотя брать то, что использовали на сервере. Теперь — есть.

Заключение


Я люблю nodeJS, люблю все те возможности, которые он открывает. Я определённо не верю в то, что весь бекенд должен быть написан на Ноде лишь потому что она «может». Однако, я убеждён, что nodeJS даёт фронтендщикам возможность полностью контролировать свою зону ответственности (фронтенд- и бекенд-UI), что позволяет делать нашу работу эффективно. Мы имеем опыт того, как выводить качественный фронтенд и мало знаем о том, как на бекенде идёт обработка данных. Расскажите нам, как получить необходимые данные и как сообщить бмзнес-логике, что делать с данными, и мы сможем создать красивый, производительный, доступный интерфейс, который будут любить клиенты.

Использование Ноды для бекенд-пользовательского интерфейса, к тому же, освобождает бекендщиков от целого ряда задач и проблем, в решении которых они не имеют заинтересованности. Мы можем добраться до создания таких веб-приложнеий, в которых фронтенд-части говорят друг с другом, не затрагивая REST-уровня, что позволяет иметь быстрые итерации интерфейса, не меняя бизнес-логики. Прыгайте в это, вода отличная!

Дисклеймер. Любая точка зрения и мнение в этой статье принадлежит Nicholas C. Zakas, и никак не отражает точек зрения моего работодателя, моих коллег, редакции книгоиздательства, где я публикуюсь, или кого-либо ещё. Я говорю только за себя, а не за них. Вы можете оставить свой ответ в комментариях.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 40

    +2
    О, спасибо, что перевели! Как раз мельком глянул на оригинал, думал, время будет — прочту. А тут со всеми удобствами.
      +25
      инженеров переднего конца
      — улыбнуло
        +28
        рыцарей «заднего конца»
        — тоже
          +1
          «там повсюду валяются грабли о двух концах»
        +20
        > Этот забавный игрушечный язык, от которого серьёзные программисты воротили носы, стал движущей силой Интернета.

        Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
          +1
          Нет, ну некоторое время его, конечно, двигал Flash…
          +4
          Сорри за не совсем по теме комментарий, но вы, видимо, оочень давно на РНР писали. За последние лет 5 не припомню проблем с отладкой кода на этом языке.

          p.s.
          Глядя на схемки в статье и вспоминая принцип бритвы Оккама, можно сказать, что возможно решение добавить слой nodejs — не совсем верное.
            +1
            Автору лучше писать комментарий в его блог, в котором оригинал статьи — он его читает.
            А вообще — да, он не сейчас работает в Yahoo, судя по биографии из его блога. И он не бекендщик.
            Про возможность первого случая он пишет — это возможно, но не лучший вариант. Почему — неразделение зон ответственности.
              +4
              поясню.
              было так

              ui-frontend — javascript
              ui-backend — php
              bl — php

              стало так
              ui-frontend — javascript
              ui-backend — javascript
              bl — php

              и теперь можно обобщить
              ui — javascript
              bl — php
              +2
              Перевод ужасен.
                +3
                Автор очень странный, в php отладка — это один из основных плюсов языка, большинство разработчиком даже дебагером не пользуются, т.к. язык изначально выбрасывает всю нужную информацию.

                Вот nodejs как раз отладкой пугает, что усложняется асинхронностью. А отлаживать нужно довольно много, так как сторонние либы довольно кривы, да и сам nodejs ещё не достиг версии 1.0. Но там где всё работает, nodejs вполне неплохой выбор, да и тот же expressjs освается за день.

                Да и странно слышать про шаблоны на php-jsp от чувака работавшего на yahoo, они же до сих пор дружат с xslt, который кроссплатформенный и поддерживается на клиенте и сервере.
                  +1
                  в php отладка — это один из основных плюсов языка, большинство разработчиком даже дебагером не пользуются, т.к. язык изначально выбрасывает всю нужную информацию.

                  Ну не скажите. С node.js у меня не было трудноуловимых проблем на продакшне только из-за того что где-то в каком-то конфигурационном php.ini-файле установлено значение, отличное от девелопмент-сервера.
                  И я всегда уверен, что js-скрипт либо отработает на «отлично», либо корректно обработает ошибку и опять же что-то ответит, а не молча проигнорирует ошибку (или не проигнорирует — надо глянуть в конфиг!) и продолжит. Или не продолжит.

                  К слову, Webstorm — очень удобный отладчик, и совсем не страшный даже учитвая асинхронность node.js.

                  PS. и вообще, в php плохо всё.
                    0
                    С, конечно, там же под каждый набор железа и ос нужно писать свой код, и приправлять ifdef.
                    nodejs — не вызовется один callback, весь сервер висит и вперёд с дебагером, чтобы найти где ошибка. у меня личный опыт отладки такого говна, это нереально нужно и долго, а то и вовсе легче либу свою написать, чем выловить рантайм баг в чужой, я либу для ftp до сих пор в кошмарах вижу, csv так же волшебным образом не конвертировал кодировку, хотя в либе есть параметр, вместо дебаша не думая заюзал exec(«iconv»), и тут же узнал что в маковских портах древнейшая версия iconv.

                    Про архитектуру php я сам могу много плохого рассказать, но в реальности с проблемами там сталкиваешься редко и их решение легко найти и легко обойти. А вот в nodejs даже лоцировать источник проблем иногда сложно, а при асинхронности дебагер слабая помощь, нужно обкладываться логами.
                      0
                      Я не совсем понял что вы хотели сказать, но вы достучились до моего сердца!
                      0
                      только из-за того что где-то в каком-то конфигурационном php.ini-файле установлено значение, отличное от девелопмент-сервера

                      А еще бывает разный веб-сервер, на продакшене и на девелопменте.
                      И базы данных разные могут быть.
                      А еще ОС разная.
                      И версии пхп тоже.

                      Как только люди умудряются писать на этом ужасном языке! Да?
                        0
                        Нет.
                        Зачем паясничать, вроде и так понятно что я имел в виду — при продакшне и так проблем хватает, зачем «искуственно» добавлять ещё и связанных с кривостью особенностью языка?

                        Я сужу по своему опыту: развёртывание и сопровождение сайтов на python+django, либо node.js — значительно проще и очевиднее чем написанных на php.
                        Конечно, дело в опыте, но меня удивляли советы действительно опытных php-программистов по устранению тех или иных проблем — настолько это порой было неочевидно.
                          0
                          при продакшне и так проблем хватает, зачем «искуственно» добавлять ещё

                          Я не знаю. Зачем Вы «искусственно» делаете дев и продакшен разными?
                          +1
                          Автор предыдущего комментария относительно прав. На PHP намного легче написать код, который будет зависим от платформы и окружения. На Java к примеру установил JDK или JRE и все работает из коробки. Не нужно ничего настраивать.
                            0
                            Либо пишем независимый от окружения код, либо зависим от окружения и создаем его для приложения. Мне кажется, это справедливо для любого языка.

                            Неужели джава каким-то магическим образом будет работать одинаково на двух серверах, с разными настройками?
                              0
                              Да это же идеология Java, чтобы код работал везде одинаково, независимо от окружения и настроек. Вообще я думаю это проблема кучи шаред хостеров PHP, которые настраивают php.ini как хотят. Если же брать Java или другой язык, который устанавливается на VDS, то часто используются настройки по-умолчанию. Максимум что меняется в Java это флаги связанные с памятью и оптимизациями, но от этого код не ломается.
                      0
                      Абстрактно это выглядит очень правильно. Но это далеко не первая абстрактная статья по теме. Хочу наконец увидеть реальный пример с кусочками кода, чтобы понять, что останется бекэндерам, а что перейдет к фронтэндерам. Мне пока трудно понять, что именно должен делать фронтэндер на сервере.
                        0
                        Рискну предположить получить данные по REST, сгенерировать шаблон если это вызов не через AJAX, если же через AJAX, отдать JSON, чтобы браузер сгенерил всё у себя
                          +1
                          Навскидку, это выглядит как двойная работа по перекидыванию данных с одного сервера на другой (плюс везде проверки нужны). Кроме того, ниже дельный комментарий про то, что не совсем понятно какие действия кому отдавать. Поэтому я пишу, что абстрактных слов мы слышали уже много, а на конкретном примере пока никто не показал, чтобы можно было разобрать плюсы и минусы на месте.
                            0
                            В том, что описал я, плюсы в одном шаблонизаторе, одних правилах валидации по формату, более-менее легкая смена бекенда, минусы были описаны ниже, в дублировании валидации формата, в лишней прослойке.
                        +7
                        Автор очень странный. Первый раз вижу сторонника ноды, который сам говорит, что нода не должна быть бекендом, а всего лишь прослойкой между бекендом и браузером.

                        Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.

                        И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
                          0
                          Вот-вот, аналогично не понимаю, как может быть достижимо это четкое разделение на практике.
                          • UFO just landed and posted this here
                            0
                            У валидации, как известно, несколько уровней — от формального (адрес почты содержит "@") до содержательного (этого адреса не содержится в БД). То, что происходит на сервере — это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще. Только сделать запрос к БД на наличие адреса и подобное. Бизнес-часть упрощается, потому что интерфейс свою задачу выполнил — дал валидные данные со всем необходимым дублированием проверок на клиенте и сервере.

                            Авторизация — это щепотка бизнес-задачи (узнать, кто обратился) и остальное — интерфейсы, от авторизации до регистрации и токенов безопасности. Модель — это вообще бизнес-логика. Передача данных от модели — это интерфейс (вью), приём команд — интерфейс (контроллер). Где дублирование кода?

                            А вообще, эта статья — видно, что полемический вброс, который недалёк от истины. Разделять слои, действительно, полезно, но не все готовы ставить на сервер Ноду. И он с этим встречался, и в наших глубинках, имею в виду всю Россию, встречается кругом. Тут, несомненно, будут противоположные мнения.
                              0
                              > это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще

                              На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.

                              > Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)

                              Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.

                              Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
                                0
                                Да, похожее я слышу и от бекендщиков — они говорят: на нашей стороне всё отлично и давно сделано, показывая строчки JSON. То, что в этих строчках — не совсем то, что надо, выясняется потом, когда они, наконец, исправляют выдачу. Так что у менеджера «ложечки находятся, а осадочек остаётся».

                                Решается это, как всегда, (содержательным) разбором содержимого обмена. Тесты с той или другой стороны, примеры бажных запросов или ответов. Но с таким же успехом могли бы быть проблемы и уровнем выше, перед сервером — не вижу разницы. И они есть. Как бекенд может подавать JSON-ошибочные данные или хуже того, рендерить неправильные блоки, которые падают на клиенте, так и клиент может недовалидировать свою долю ответственности.

                                Авторизация — если она нужна там и там, то это не дублирование, а использование результатов? Бекенд-логика сказала, что есть права доступа, этот факт используется там и там. Бекенд-UI не требуется повторной авторизации, только запроса на неё.

                                Meteor — то, что про его необходимость нигде не говорится, показывает, что проблема есть, но решается она не обязательно полным переходом на JS. Достаточно иметь интерфейс внутри сервера между слоями. А слои реально существуют, не высосаны из пальца или «не приснились», как пишет в комменте Закас.

                                И, как я понимаю, не обязательно иметь внутренний межсерверный интерфейс — есть сокеты и вызовы процедур на других языках, есть сигналы и передача данных через файлы или БД. Почему говорят именно о REST — наверное, так проще и стандартнее, масштабируемее. Этот вопрос, кстати, тоже там поднимали — не будет ли это медленно.
                            0
                            NodeJS потащил за собой на сервера не только JavaScript, а еще и асинхронную архитектуру, что на мой взгляд более весомее чем новый язык на backend-е.
                              +4
                              Асинхронная архитектура появилась задолго до появления NodeJS, поэтому не совсем понятно, почему вы это относите к ключевым преимуществам ноды.
                                +1
                                Я не говорю про преимущества, просто он ее популяризировал.
                              +1
                              А разве дополнительная прослойка в виде HTTP Rest не будет создавать дополнительный overhead, задержки и т.п. К примеру чистый TCP сервер-клиент, который работает с бинарными данными будет работать намного быстрее. (Thrift, Protobuf как пример).
                                +1
                                Если честно, вообще не понимаю практический смысл прослойки на ноде, что подразумевается под backend UI? Рендер html шаблона? Не лучше ли в таком случае отдать эту роль браузерному яваскрипту — получаем шаблон, данные и рендерим их.
                                  +1
                                  Ответы на многие заданные здесь вопросы дали за последнюю неделю среди 80 комментариев оригинала автор статьи и часть читателей. У них там обсуждение получилось закономерно оживлённее, чем у нас — ведь технологии применяются несколько шире и раньше. У нас пока — только вопросы, и ни одного реального свидетельства решения в том же ключе. Там многие (4-5 комментов) сказали, что с точно такими же проблемами сталкиваются в реальной работе. 3-4 человек выразили радость по поводу того, что кто-то это сформулировал. Человек 10 задали вопросы, подобные нашим и человек 5 произнесли аргументированную критику.

                                  К примеру, на Ваш вопрос Закас ответил (там, к сожалению, якорей у комментов нет): "John – front-end UI layer is the delivered HTML, CSS, JavaScript, images, etc. Back-end UI layer is templating, data fetching and cooking, etc."

                                  Рендеринг шаблонов — часть таких задач, когда серверу нужно отдать готовый HTML старому клиенту или поисковику. У нас это тоже начинает применяться не дублированием кода на PHP, а применением JS-шаблонизаторов типа Jade, которые на сервере под Нодой тоже умеют обрабатывать шаблоны. Конечно, есть решения данной задачи в PHP или Ruby — в процедурах поддержки Mustache, например. Только это — лишь одна из задач прослойки, хорошо решённая в одном из шаблонизаторов.
                                    +1
                                    В Mustache, увы, нет ничего хорошего кроме поддерижваемости.
                                  +5
                                  Давно применяю такой подход к разработке (очень успешно). Такое архитектурное решение я считаю наиболее эффективным из всех, что я применял. А роль Node-ы, как аггрегатора API, более чем опревдана и уместна. Про этот подход я отчасти рассказывал на html5camp.
                                    –1
                                    На фронтенде все чинно и гладко, на бэкэнде разработчики сидят пилят себе потихоньку, код вылизывают, все Ок!
                                    а то, что между ними пропасть, (которая прослеживается даже в комментариях к этому топику) видит лишь менеджер проекта…

                                    Вот и сидят они выстраивают натяжные мосты над этой пропастью нагружая код проверками, ведь как выше заметили, это почти разные стороны баррикад и верить друг-другу они не будут… А работать над проектом, а не над кодом на любимом языке программирования, умеют лишь профессионалы, которые скоро совсем вымрут как мамонты…
                                    Зато «студентов» которые готовы часами обсуждать почему отладка на его любимом языке круче, чем на другом менее ему знакомом — как собак в спальных районах…

                                    В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!

                                    Правда, возможно, придется уволить PHP-шников...)
                                      +1
                                      > В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!

                                      Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.

                                      Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.

                                      Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.

                                    Only users with full accounts can post comments. Log in, please.