Comments 40
О, спасибо, что перевели! Как раз мельком глянул на оригинал, думал, время будет — прочту. А тут со всеми удобствами.
инженеров переднего конца— улыбнуло
> Этот забавный игрушечный язык, от которого серьёзные программисты воротили носы, стал движущей силой Интернета.
Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
Сорри за не совсем по теме комментарий, но вы, видимо, оочень давно на РНР писали. За последние лет 5 не припомню проблем с отладкой кода на этом языке.
p.s.
Глядя на схемки в статье и вспоминая принцип бритвы Оккама, можно сказать, что возможно решение добавить слой nodejs — не совсем верное.
p.s.
Глядя на схемки в статье и вспоминая принцип бритвы Оккама, можно сказать, что возможно решение добавить слой nodejs — не совсем верное.
Автору лучше писать комментарий в его блог, в котором оригинал статьи — он его читает.
А вообще — да, он не сейчас работает в Yahoo, судя по биографии из его блога. И он не бекендщик.
Про возможность первого случая он пишет — это возможно, но не лучший вариант. Почему — неразделение зон ответственности.
А вообще — да, он не сейчас работает в Yahoo, судя по биографии из его блога. И он не бекендщик.
Про возможность первого случая он пишет — это возможно, но не лучший вариант. Почему — неразделение зон ответственности.
поясню.
было так
ui-frontend — javascript
ui-backend — php
bl — php
стало так
ui-frontend — javascript
ui-backend — javascript
bl — php
и теперь можно обобщить
ui — javascript
bl — php
было так
ui-frontend — javascript
ui-backend — php
bl — php
стало так
ui-frontend — javascript
ui-backend — javascript
bl — php
и теперь можно обобщить
ui — javascript
bl — php
Перевод ужасен.
Автор очень странный, в php отладка — это один из основных плюсов языка, большинство разработчиком даже дебагером не пользуются, т.к. язык изначально выбрасывает всю нужную информацию.
Вот nodejs как раз отладкой пугает, что усложняется асинхронностью. А отлаживать нужно довольно много, так как сторонние либы довольно кривы, да и сам nodejs ещё не достиг версии 1.0. Но там где всё работает, nodejs вполне неплохой выбор, да и тот же expressjs освается за день.
Да и странно слышать про шаблоны на php-jsp от чувака работавшего на yahoo, они же до сих пор дружат с xslt, который кроссплатформенный и поддерживается на клиенте и сервере.
Вот nodejs как раз отладкой пугает, что усложняется асинхронностью. А отлаживать нужно довольно много, так как сторонние либы довольно кривы, да и сам nodejs ещё не достиг версии 1.0. Но там где всё работает, nodejs вполне неплохой выбор, да и тот же expressjs освается за день.
Да и странно слышать про шаблоны на php-jsp от чувака работавшего на yahoo, они же до сих пор дружат с xslt, который кроссплатформенный и поддерживается на клиенте и сервере.
в php отладка — это один из основных плюсов языка, большинство разработчиком даже дебагером не пользуются, т.к. язык изначально выбрасывает всю нужную информацию.
Ну не скажите. С node.js у меня не было трудноуловимых проблем на продакшне только из-за того что где-то в каком-то конфигурационном php.ini-файле установлено значение, отличное от девелопмент-сервера.
И я всегда уверен, что js-скрипт либо отработает на «отлично», либо корректно обработает ошибку и опять же что-то ответит, а не молча проигнорирует ошибку (или не проигнорирует — надо глянуть в конфиг!) и продолжит. Или не продолжит.
К слову, Webstorm — очень удобный отладчик, и совсем не страшный даже учитвая асинхронность node.js.
PS. и вообще, в php плохо всё.
С, конечно, там же под каждый набор железа и ос нужно писать свой код, и приправлять ifdef.
nodejs — не вызовется один callback, весь сервер висит и вперёд с дебагером, чтобы найти где ошибка. у меня личный опыт отладки такого говна, это нереально нужно и долго, а то и вовсе легче либу свою написать, чем выловить рантайм баг в чужой, я либу для ftp до сих пор в кошмарах вижу, csv так же волшебным образом не конвертировал кодировку, хотя в либе есть параметр, вместо дебаша не думая заюзал exec(«iconv»), и тут же узнал что в маковских портах древнейшая версия iconv.
Про архитектуру php я сам могу много плохого рассказать, но в реальности с проблемами там сталкиваешься редко и их решение легко найти и легко обойти. А вот в nodejs даже лоцировать источник проблем иногда сложно, а при асинхронности дебагер слабая помощь, нужно обкладываться логами.
nodejs — не вызовется один callback, весь сервер висит и вперёд с дебагером, чтобы найти где ошибка. у меня личный опыт отладки такого говна, это нереально нужно и долго, а то и вовсе легче либу свою написать, чем выловить рантайм баг в чужой, я либу для ftp до сих пор в кошмарах вижу, csv так же волшебным образом не конвертировал кодировку, хотя в либе есть параметр, вместо дебаша не думая заюзал exec(«iconv»), и тут же узнал что в маковских портах древнейшая версия iconv.
Про архитектуру php я сам могу много плохого рассказать, но в реальности с проблемами там сталкиваешься редко и их решение легко найти и легко обойти. А вот в nodejs даже лоцировать источник проблем иногда сложно, а при асинхронности дебагер слабая помощь, нужно обкладываться логами.
только из-за того что где-то в каком-то конфигурационном php.ini-файле установлено значение, отличное от девелопмент-сервера
А еще бывает разный веб-сервер, на продакшене и на девелопменте.
И базы данных разные могут быть.
А еще ОС разная.
И версии пхп тоже.
Как только люди умудряются писать на этом ужасном языке! Да?
Нет.
Зачем паясничать, вроде и так понятно что я имел в виду — при продакшне и так проблем хватает, зачем «искуственно» добавлять ещё и связанных скривостью особенностью языка?
Я сужу по своему опыту: развёртывание и сопровождение сайтов на python+django, либо node.js — значительно проще и очевиднее чем написанных на php.
Конечно, дело в опыте, но меня удивляли советы действительно опытных php-программистов по устранению тех или иных проблем — настолько это порой было неочевидно.
Зачем паясничать, вроде и так понятно что я имел в виду — при продакшне и так проблем хватает, зачем «искуственно» добавлять ещё и связанных с
Я сужу по своему опыту: развёртывание и сопровождение сайтов на python+django, либо node.js — значительно проще и очевиднее чем написанных на php.
Конечно, дело в опыте, но меня удивляли советы действительно опытных php-программистов по устранению тех или иных проблем — настолько это порой было неочевидно.
Автор предыдущего комментария относительно прав. На PHP намного легче написать код, который будет зависим от платформы и окружения. На Java к примеру установил JDK или JRE и все работает из коробки. Не нужно ничего настраивать.
Либо пишем независимый от окружения код, либо зависим от окружения и создаем его для приложения. Мне кажется, это справедливо для любого языка.
Неужели джава каким-то магическим образом будет работать одинаково на двух серверах, с разными настройками?
Неужели джава каким-то магическим образом будет работать одинаково на двух серверах, с разными настройками?
Да это же идеология Java, чтобы код работал везде одинаково, независимо от окружения и настроек. Вообще я думаю это проблема кучи шаред хостеров PHP, которые настраивают php.ini как хотят. Если же брать Java или другой язык, который устанавливается на VDS, то часто используются настройки по-умолчанию. Максимум что меняется в Java это флаги связанные с памятью и оптимизациями, но от этого код не ломается.
Абстрактно это выглядит очень правильно. Но это далеко не первая абстрактная статья по теме. Хочу наконец увидеть реальный пример с кусочками кода, чтобы понять, что останется бекэндерам, а что перейдет к фронтэндерам. Мне пока трудно понять, что именно должен делать фронтэндер на сервере.
Рискну предположить получить данные по REST, сгенерировать шаблон если это вызов не через AJAX, если же через AJAX, отдать JSON, чтобы браузер сгенерил всё у себя
Навскидку, это выглядит как двойная работа по перекидыванию данных с одного сервера на другой (плюс везде проверки нужны). Кроме того, ниже дельный комментарий про то, что не совсем понятно какие действия кому отдавать. Поэтому я пишу, что абстрактных слов мы слышали уже много, а на конкретном примере пока никто не показал, чтобы можно было разобрать плюсы и минусы на месте.
Автор очень странный. Первый раз вижу сторонника ноды, который сам говорит, что нода не должна быть бекендом, а всего лишь прослойкой между бекендом и браузером.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Вот-вот, аналогично не понимаю, как может быть достижимо это четкое разделение на практике.
У валидации, как известно, несколько уровней — от формального (адрес почты содержит "@") до содержательного (этого адреса не содержится в БД). То, что происходит на сервере — это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще. Только сделать запрос к БД на наличие адреса и подобное. Бизнес-часть упрощается, потому что интерфейс свою задачу выполнил — дал валидные данные со всем необходимым дублированием проверок на клиенте и сервере.
Авторизация — это щепотка бизнес-задачи (узнать, кто обратился) и остальное — интерфейсы, от авторизации до регистрации и токенов безопасности. Модель — это вообще бизнес-логика. Передача данных от модели — это интерфейс (вью), приём команд — интерфейс (контроллер). Где дублирование кода?
А вообще, эта статья — видно, что полемический вброс, который недалёк от истины. Разделять слои, действительно, полезно, но не все готовы ставить на сервер Ноду. И он с этим встречался, и в наших глубинках, имею в виду всю Россию, встречается кругом. Тут, несомненно, будут противоположные мнения.
Авторизация — это щепотка бизнес-задачи (узнать, кто обратился) и остальное — интерфейсы, от авторизации до регистрации и токенов безопасности. Модель — это вообще бизнес-логика. Передача данных от модели — это интерфейс (вью), приём команд — интерфейс (контроллер). Где дублирование кода?
А вообще, эта статья — видно, что полемический вброс, который недалёк от истины. Разделять слои, действительно, полезно, но не все готовы ставить на сервер Ноду. И он с этим встречался, и в наших глубинках, имею в виду всю Россию, встречается кругом. Тут, несомненно, будут противоположные мнения.
> это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Да, похожее я слышу и от бекендщиков — они говорят: на нашей стороне всё отлично и давно сделано, показывая строчки JSON. То, что в этих строчках — не совсем то, что надо, выясняется потом, когда они, наконец, исправляют выдачу. Так что у менеджера «ложечки находятся, а осадочек остаётся».
Решается это, как всегда, (содержательным) разбором содержимого обмена. Тесты с той или другой стороны, примеры бажных запросов или ответов. Но с таким же успехом могли бы быть проблемы и уровнем выше, перед сервером — не вижу разницы. И они есть. Как бекенд может подавать JSON-ошибочные данные или хуже того, рендерить неправильные блоки, которые падают на клиенте, так и клиент может недовалидировать свою долю ответственности.
Авторизация — если она нужна там и там, то это не дублирование, а использование результатов? Бекенд-логика сказала, что есть права доступа, этот факт используется там и там. Бекенд-UI не требуется повторной авторизации, только запроса на неё.
Meteor — то, что про его необходимость нигде не говорится, показывает, что проблема есть, но решается она не обязательно полным переходом на JS. Достаточно иметь интерфейс внутри сервера между слоями. А слои реально существуют, не высосаны из пальца или «не приснились», как пишет в комменте Закас.
И, как я понимаю, не обязательно иметь внутренний межсерверный интерфейс — есть сокеты и вызовы процедур на других языках, есть сигналы и передача данных через файлы или БД. Почему говорят именно о REST — наверное, так проще и стандартнее, масштабируемее. Этот вопрос, кстати, тоже там поднимали — не будет ли это медленно.
Решается это, как всегда, (содержательным) разбором содержимого обмена. Тесты с той или другой стороны, примеры бажных запросов или ответов. Но с таким же успехом могли бы быть проблемы и уровнем выше, перед сервером — не вижу разницы. И они есть. Как бекенд может подавать JSON-ошибочные данные или хуже того, рендерить неправильные блоки, которые падают на клиенте, так и клиент может недовалидировать свою долю ответственности.
Авторизация — если она нужна там и там, то это не дублирование, а использование результатов? Бекенд-логика сказала, что есть права доступа, этот факт используется там и там. Бекенд-UI не требуется повторной авторизации, только запроса на неё.
Meteor — то, что про его необходимость нигде не говорится, показывает, что проблема есть, но решается она не обязательно полным переходом на JS. Достаточно иметь интерфейс внутри сервера между слоями. А слои реально существуют, не высосаны из пальца или «не приснились», как пишет в комменте Закас.
И, как я понимаю, не обязательно иметь внутренний межсерверный интерфейс — есть сокеты и вызовы процедур на других языках, есть сигналы и передача данных через файлы или БД. Почему говорят именно о REST — наверное, так проще и стандартнее, масштабируемее. Этот вопрос, кстати, тоже там поднимали — не будет ли это медленно.
NodeJS потащил за собой на сервера не только JavaScript, а еще и асинхронную архитектуру, что на мой взгляд более весомее чем новый язык на backend-е.
А разве дополнительная прослойка в виде HTTP Rest не будет создавать дополнительный overhead, задержки и т.п. К примеру чистый TCP сервер-клиент, который работает с бинарными данными будет работать намного быстрее. (Thrift, Protobuf как пример).
Если честно, вообще не понимаю практический смысл прослойки на ноде, что подразумевается под backend UI? Рендер html шаблона? Не лучше ли в таком случае отдать эту роль браузерному яваскрипту — получаем шаблон, данные и рендерим их.
Ответы на многие заданные здесь вопросы дали за последнюю неделю среди 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, например. Только это — лишь одна из задач прослойки, хорошо решённая в одном из шаблонизаторов.
К примеру, на Ваш вопрос Закас ответил (там, к сожалению, якорей у комментов нет): "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, например. Только это — лишь одна из задач прослойки, хорошо решённая в одном из шаблонизаторов.
Давно применяю такой подход к разработке (очень успешно). Такое архитектурное решение я считаю наиболее эффективным из всех, что я применял. А роль Node-ы, как аггрегатора API, более чем опревдана и уместна. Про этот подход я отчасти рассказывал на html5camp.
На фронтенде все чинно и гладко, на бэкэнде разработчики сидят пилят себе потихоньку, код вылизывают, все Ок!
а то, что между ними пропасть, (которая прослеживается даже в комментариях к этому топику) видит лишь менеджер проекта…
Вот и сидят они выстраивают натяжные мосты над этой пропастью нагружая код проверками, ведь как выше заметили, это почти разные стороны баррикад и верить друг-другу они не будут… А работать над проектом, а не над кодом на любимом языке программирования, умеют лишь профессионалы, которые скоро совсем вымрут как мамонты…
Зато «студентов» которые готовы часами обсуждать почему отладка на его любимом языке круче, чем на другом менее ему знакомом — как собак в спальных районах…
В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Правда, возможно, придется уволить PHP-шников...)
а то, что между ними пропасть, (которая прослеживается даже в комментариях к этому топику) видит лишь менеджер проекта…
Вот и сидят они выстраивают натяжные мосты над этой пропастью нагружая код проверками, ведь как выше заметили, это почти разные стороны баррикад и верить друг-другу они не будут… А работать над проектом, а не над кодом на любимом языке программирования, умеют лишь профессионалы, которые скоро совсем вымрут как мамонты…
Зато «студентов» которые готовы часами обсуждать почему отладка на его любимом языке круче, чем на другом менее ему знакомом — как собак в спальных районах…
В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Правда, возможно, придется уволить PHP-шников...)
> В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
Sign up to leave a comment.
Node.js и новый фронтенд в вебе