Теперь представьте что это сказал хирург. Раз Вы пришли на собеседование по математике будьте добры решать соответствующие задачи.
А иначе если 15 лет назад решали задачи которые нужны сейчас под проект о чем написано в вакансии, а Вы не подготовились, тогда извините Вы не подходите на проект.
Вам нужен shadow DOM чтобы писать на любом из современных фреймворков?) зачем тогда он Вам нужен чтобы писать на веб компонентах? А бандл будет намного меньше и шустрее. Посмотрите в сторону web components compilers (один из них https://stenciljs.com)
Как уже писал это или команда джунов или автомейшн билд. В зависимости от сложности взаимодействия. В Вашем случае это билд
Не нужно им ничего понимать. Им нужно знать что дать на вход и нужно ли что-то ожидать на выходе. Инкапсуляция и все дела :) на самом деле конечный продукт будет собираться очень быстро и очень просто.
Возможно Вы правы. Но все же, на фронте один Локал сторадж, window, document и ещё куча всего. На backend такого нет, или же не должно быть.
Все очень просто если следовать компонентной структуре. А с перформансом все вообще будет зашибись если использовать один Фреймворк ;) или не использовать вообще
Описание:
К-во команд равно к-во микросервисов +1 (product team)
Каждая команда пишет 1 или набор web components (я о стандрарте который поддерживают большинство современных броузеров); под капом что угодно, например Stenciljs или тяжеловесы как React и Angular, как и любой компонент они ожидают параметры и викидывают какие-то ивенты
Product team объединяет компоненты написанные другими командами в одно целое (в зависимости от простоты внедрения зависимостей команда может состоять из джунов или заменена на автомейшн build)
Продукт пишется на любом доступном фреймворке или без него. Веб компоненты получают все необходимые данные, продуктовая команда решает что делать если сервисный компонент выбросил ошибку.
Понятие «микросервисы» не применимо на фронтенде, среда то одна ;)
Такую систему назвал бы модульная, с возможность писать на любом фреймворке, что все-равно будет выливатся в проблемы с перформансом и размером конечного бандла и конечным к-во JSa который нужно парсить браузеру.
так а "вежливо спросить" кого? Воздух? Если человек не удосужился помочь написанием комментария сразу, то почему он поступит наоборот когда кто-то напишет в воздух?
Они переписывают Ionic на stenciljs и потом Ionic можно будет использовать с любым фреймворком.
Думаю они пока не парятся за популярность stencil, так как Это просто сайд продукт
Производительность имеет огромное значение, если Вы пишете мобильное приложение :) Вы же не хотите чтобы Ваши пользователи говорили что оно глючное (3G, покрытие и т.д.).
Поэтому 4 промиса решают проблему объединения данных, но Вы каждый раз будете тратить время на соединение, проверку CORS, авторизацию, права доступа и что там еще есть. А так — все за один раз.
Согласен на счет ресурса агрегатора, но это в том или ином виде получится GraphQL.
Кстати, я не думаю, что GraphQL полностью вытеснит REST. GraphQL очень хорошо работает для микросервисных архитектур как API Gateway наружу. А внутри проще использовать REST или RPC.
В REST URL является уникальным идентификатором для ресурса. Поэтому если у Вас на GET /articles можно запросить и еще кучу всего не связанного, то это уже не REST, так как теряется смысл урлов вообще. Ведь можно просто сделать GET /api, который по GET параметрах возвращает все что угодно. И тогда Ваш REST эволюционирует в oData или GraphQL :)
Единственное почему graphQL лучше за REST — это то что Вы можете запросить совсем не связанные ресурсы одним запросом.
Например, в блог приложении Вы можете единственным запросом:
статьи из рубрики с учетом пагинации
топ авторов
топ статьи
топ комментарии
Аналогично можно сохранить сразу пачку не связанных сущностей.
В остальном все то же самое можно сделать в REST. Как правильно упоминали в комментариях, еще в 2007 Microsoft придумало стандарт oData, который решает те же проблемы. Но почему-то такого ажиотажа, как c GraphQL — не было :)
Вот недавно нашел полезный проект https://github.com/Inchoo/Inchoo_PHP7. Говорят на PHP7 Magento 1.x может обрабатывать чуть ли не в 2 раза больше запросов.
Сейчас есть проекты crosswalk, wk-webview, ionic2, которые вывели гибридную разработку совсем на другой уровень. (Не вижу упоминания об этом)
А если вам нужна 3д анимация и прочие рил-тайм штучки, пожалуйста, пишите нативный плагин и продолжайте разработку на веб технологиях. Тогда вам не нужно в штат 3 девелопера нативщика. Можно использовать фриланс, аутсорс или 1 адекватного программиста, который напишет нужный плагин когда это потребуется.
Очень крутая статья по теме: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
Теперь представьте что это сказал хирург. Раз Вы пришли на собеседование по математике будьте добры решать соответствующие задачи.
А иначе если 15 лет назад решали задачи которые нужны сейчас под проект о чем написано в вакансии, а Вы не подготовились, тогда извините Вы не подходите на проект.
Все очень просто если следовать компонентной структуре. А с перформансом все вообще будет зашибись если использовать один Фреймворк ;) или не использовать вообще
Описание:
Понятие «микросервисы» не применимо на фронтенде, среда то одна ;)
Такую систему назвал бы модульная, с возможность писать на любом фреймворке, что все-равно будет выливатся в проблемы с перформансом и размером конечного бандла и конечным к-во JSa который нужно парсить браузеру.
так а "вежливо спросить" кого? Воздух? Если человек не удосужился помочь написанием комментария сразу, то почему он поступит наоборот когда кто-то напишет в воздух?
Они переписывают Ionic на stenciljs и потом Ionic можно будет использовать с любым фреймворком.
Думаю они пока не парятся за популярность stencil, так как Это просто сайд продукт
https://stenciljs.com/ попадает в ту же категорию, от разработчиков Ionic.
Производительность имеет огромное значение, если Вы пишете мобильное приложение :) Вы же не хотите чтобы Ваши пользователи говорили что оно глючное (3G, покрытие и т.д.).
Поэтому 4 промиса решают проблему объединения данных, но Вы каждый раз будете тратить время на соединение, проверку CORS, авторизацию, права доступа и что там еще есть. А так — все за один раз.
Согласен на счет ресурса агрегатора, но это в том или ином виде получится GraphQL.
Кстати, я не думаю, что GraphQL полностью вытеснит REST. GraphQL очень хорошо работает для микросервисных архитектур как API Gateway наружу. А внутри проще использовать REST или RPC.
В REST URL является уникальным идентификатором для ресурса. Поэтому если у Вас на GET /articles можно запросить и еще кучу всего не связанного, то это уже не REST, так как теряется смысл урлов вообще. Ведь можно просто сделать GET /api, который по GET параметрах возвращает все что угодно. И тогда Ваш REST эволюционирует в oData или GraphQL :)
Единственное почему graphQL лучше за REST — это то что Вы можете запросить совсем не связанные ресурсы одним запросом.
Например, в блог приложении Вы можете единственным запросом:
Аналогично можно сохранить сразу пачку не связанных сущностей.
В остальном все то же самое можно сделать в REST. Как правильно упоминали в комментариях, еще в 2007 Microsoft придумало стандарт oData, который решает те же проблемы. Но почему-то такого ажиотажа, как c GraphQL — не было :)
Вот интересное сравнение — https://www.progress.com/blogs/rest-api-industry-debate-odata-vs-graphql-vs-ords
Я так понимаю основная проблема в этом? В реализации декоратора. Правильно?
Вот интересная статья — https://www.magecore.com/blog/developers-tips/php-7-affects-performance-magento-1-9-ce-vs-magento-2-0-ce
«Нет оправдания для говнокодерства, кроме как лень и деньги» (с)
Обзор не серьезный. Много воды и не о чем.
Сейчас есть проекты crosswalk, wk-webview, ionic2, которые вывели гибридную разработку совсем на другой уровень. (Не вижу упоминания об этом)
А если вам нужна 3д анимация и прочие рил-тайм штучки, пожалуйста, пишите нативный плагин и продолжайте разработку на веб технологиях. Тогда вам не нужно в штат 3 девелопера нативщика. Можно использовать фриланс, аутсорс или 1 адекватного программиста, который напишет нужный плагин когда это потребуется.