Я вот не совсем согласен, что главное достоинство изоморфности — это скорость начальной загрузки страницы. Потому что js-файл приложения будет грузиться только 1 раз, при самом первом открытии сайта пользователем. Во всех остальных случаях он будет подгружаться из кэша браузера, а с сервера будет запрашиваться только легкий json. И вот когда js уже в кэше нашего браузера, и мы жмем f5 для полной перезагрузки страницы, то далеко не факт, что рендеринг всей страницы на сервере будет быстрее, чем запросить json (вместо того чтобы тянуть с сервера весь html целиком) и вставить его на клиенте в нужные блоки.
На мой взгляд, гораздо более полезная плюшка изоморфности — это решение проблем с поисковиками, потому что мы пишем код только один раз, и он дает один и тот же результат и поисковику и человеку в браузере. Это избавляет нас от костыльных решений типа генерации снапшотов страниц по крону, или хуже того, написания второго приложения специально для поисковиков.
Нужно просто понимать, что ситуации бывают разные. Подход, который советует автор статьи, очень хорошо подходит для больших состоявшихся компаний с готовым продуктом, кучей legacy-кода и неприоритетных задач. Если же у вас команда из пяти человек, жесткие сроки и 85% времени пишется новый функционал, то нанимать джуниоров вместо миддлов и сеньоров будет провальной стратегией. Потому что в данном случае, найми ты хоть трех джуниоров с зарплатой 40к — они не дадут такой эффективности, какую бы дал один сильный миддл или сеньор за 150к.
Действительно, как же связан метод «jsonSerialize» в модели с представлением этой модели в формате JSON)))
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
Я много раз спорил со знакомыми, пишущими на Laravel, что модель — это слой данных, который не должен ничего знать о том, в каком формате он будет представлен для пользователя, и все эти «implements JsonSerializable» у модели — это неверно. По мне, так данная статья еще раз это подтверждает.
Так хотя бы вот этот. Это более-менее распространенный, хорошо оформленный стандарт.
сразу с БД отправлять в джаваскрипт
А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
А я считаю, что каждый язык должен использовать свой style guide. У SQL свой, у PHP свой, у JSON-API свой. У меня был случай, что мне нужно было перенести проект на другой язык. И что мне, всю схему БД менять? Или добавился второй клиент, использующий JSON-API, написанный на языке с другим стилем именования переменных.
Если, как вы заметили, многие сделали вам замечание по поводу имен полей — так, может быть, действительно что-то не так?
P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
Я бы не стал называть его просто «каким-то чуваком» =) Я просто привожу в пример реально существующий стайл-гайд, где четко указано использовать «underscore». И я знаю людей и команды, которые придерживаются его (за неимением официального от MySQL или PostgreSQL). По мне, так достаточно нормальный аргумент, если учесть что в поддержку CamelCase я не вижу ничего кроме вкусовых предпочтений отдельных людей.
Не знаю, на мой взгляд, полный объектный маппинг не такая уж и нужная вещь. Может, вы потратите немножко больше времени при написании миграций вручную, но зато можно делать гораздо более гибкие вещи, чем при их автоматической генерации.
Интересно, почему на одну и ту же позицию взяли кандидатов такого несравнимого уровня?) Двое только-только начали программировать, а третий — человек, пишущий парсеры, знающий многопоточность, асинхронность, очереди задач, юнит-тесты и с опытом Python N лет =)
Для примера простой сайт на PHPixie заработал почти в три раза быстрее практически сравнившись со скоростью Phalcon на PHP 5.6, несколько сайтов на Wordpress показали стабильный прирост в скорости в два раза.
Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)
Если вы придумали новую иконку и думаете, что нужно к ней подставить небольшую подсказку, то вы не правы.
Я думаю, лучше так:
«Если вы создали новую иконку, и чувствуете, что к ней требуется небольшая подсказка, для того чтобы сделать ее пригодной к использованию — значит, вы спроектировали ее неправильно.»
Иначе белиберда какая-то получается по смыслу.
Написать универсальный движок интернет-магазинов для продажи и написать магазин под свой бизнес (или просто заточить какой-то движок) — это абсолютно разные вещи и по трудозатратам, и по целям. Не нужно их путать.
Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.
На мой взгляд, гораздо более полезная плюшка изоморфности — это решение проблем с поисковиками, потому что мы пишем код только один раз, и он дает один и тот же результат и поисковику и человеку в браузере. Это избавляет нас от костыльных решений типа генерации снапшотов страниц по крону, или хуже того, написания второго приложения специально для поисковиков.
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
Первая ссылка в google по «sql style guide»:
Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)
Я думаю, лучше так:
«Если вы создали новую иконку, и чувствуете, что к ней требуется небольшая подсказка, для того чтобы сделать ее пригодной к использованию — значит, вы спроектировали ее неправильно.»
Иначе белиберда какая-то получается по смыслу.
Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.