По поводу динамической подгрузки веб-компонентов, можете сказать на сколько большими они у вас получились, что пришлось делать Lazy Loading?
И на сколько, на ваш взгляд, стоит заморачиваться с общим решением для этого? Судя по моему опыту и issue в большинстве случаев при разработке приложений routing и code splitting решает проблему больших бандлов. Помимо него можно воспользоваться динамической загрузкой дочерних компонентов из основного по разного рода хукам (как понимаю, в последнем списке вы один из таки алгоритмов и описываете).
Наше API состоит из двух основных частей GRPC и GraphQL сервера (прослойки). Сейчас можно говорить что GRPC сервер отчасти следует паттерну API Gateway. Что касается прослойки, то на её стороне пока используется только один сервис, собственно GRPC. У Apollo ещё есть инструмент использования micro-schemas, когда несколько микросервисов предоставляют схемы своих API, а шлюз их объединяет и отдает конечному клиенту в виде единого API. Это кажется достаточно интересным, но требует высокого уровня развития микросервисов.
Спасибо, в статье не упомянул, но у нас уже разрабатывается несколько новых клиентских приложений. И да, проще один раз согласоваться на схемах API, чем проходить этот путь для каждого из клиентов.
Разработка ПО и программирование как частность в моем понимании это управление сложностью (если отбросить шелуху в виде технологий и инструментов). По факту мы действительно решаем те же задачи, но более технологичные, т.е. более сложные. Поэтому и требуются новые подходы и инструменты.
Всё о чем я пишу в статье к сайту компании никакого отношения не имеет, им занимается отдельная команда. Мы работаем над продуктом BILLmanager (почитать про него можно здесь www.ispsystem.ru/software/billmanager, там же есть ссылка на demo). На demo нет новой API, но общие объемы задач, которые подтолкнули нас к изменениям можно увидеть.
Правильно говорите тема IT хайповая. Разобраться в чем-то бывает не просто, всё усложняется ещё и тем, что многие зарабатывают на этом хайпе. В итоге чтобы найти реально полезные вещи приходится сначала наступить на много граблей. Я описал реальную ситуацию — огромный проект с большим легаси, чтобы развиваться пришлось начать многое изменять (что-то из этого получилось, что-то нет). Надеюсь кому-то это подскажет решение их проблем и получится пройти наш путь проще и быстрее.
Пока детальных нагрузочных тестов не проводили. Замеряли производительность клиентских приложений до и после перевода на GraphQL, просадку не заметили. Вообще судя по обзорам и статьям сам по себе GraphQL сильных тормозов давать не должен. В любом случае спасибо за наводку, покопаю в этом направлении.
Спасибо за статью, познавательно, есть что вспомнить)
А по поводу недалекого будущего, думаю все больше люди станут переходить с привычных хостингов на разного рода saas, paas и т.д.
Эта тенденция уже сегодня хорошо просматривается, возможно из-за этого обычный хостинг и перестал так стремительно, как раньше, падать в цене. Думаю, что в будующем vds и vdc хостинг будет интересовать в основном средний бизнес, которому нужна надежная инфраструктура, но не целесообразно её создавать самостоятельно.
Наш первый конфиг в общем то это и делал, но это опасный путь) Есть высокая степень вероятности, что при очередном обновлении проект не запустится т.к. разработчики Angular добавили новый «аспект», который учитывается в @ngtools/webpack а вот в ts-loader или awesome-typescript-loader его ещё нужно правильно обработать. По поводу uglify, знаю, что внутри CLI при сборке он тоже используется, про google closure compiler ничего сказать не могу, не использовал.
Говоря Angular 6 я подразумеваю экосистему Angular — это и rxjs внутри него и CLI и все остальное необходимое для получения конечного приложения, способного запуститься в браузере пользователя. Если рассматривать экосистему Angular 6 то по-умолчанию (здесь можно трактовать по-умолчанию=Angular CLI) в ней используется Webpack 4. Хотя, конечно, Angular 6 можно попробовать собрать Webpack 3 и даже rollup.js :)
Да, точно, спасибо поправил :)
Это в ходе экспериментов так выключал/включал дополнительные проверки в попытках ускорить сборку, а обратно для статьи поменять забыл.
Основных мотиваций для обновления было две:
1. Хотелось ускорить сборку проекта. Уже давно следим за новостями по Webpack 4. В этом видео Sean Larkin рассказывает подробнее. Angular 6 по-умолчанию использует Webpack 4 поэтому решили обновлять совместно. В итоге сейчас проект стал собираться на 40 секунд быстрее (думаю можно будет еще ускорить, но уже приятно).
2. С каждым обновлением команда Angular вносит ряд изменений в фреймворк, которые требуют переработки компонентов. Если затягивать с обновлением, то потом придется менять слишком много кода. Даже в update.angular.io если указать переход через несколько мажорных версии они напишут предупреждение:
Warning: We do not recommend moving across multiple major versions.
Полезная статья, спасибо за труд.
По поводу динамической подгрузки веб-компонентов, можете сказать на сколько большими они у вас получились, что пришлось делать Lazy Loading?
И на сколько, на ваш взгляд, стоит заморачиваться с общим решением для этого? Судя по моему опыту и issue в большинстве случаев при разработке приложений routing и code splitting решает проблему больших бандлов. Помимо него можно воспользоваться динамической загрузкой дочерних компонентов из основного по разного рода хукам (как понимаю, в последнем списке вы один из таки алгоритмов и описываете).
Всё о чем я пишу в статье к сайту компании никакого отношения не имеет, им занимается отдельная команда. Мы работаем над продуктом BILLmanager (почитать про него можно здесь www.ispsystem.ru/software/billmanager, там же есть ссылка на demo). На demo нет новой API, но общие объемы задач, которые подтолкнули нас к изменениям можно увидеть.
Правильно говорите тема IT хайповая. Разобраться в чем-то бывает не просто, всё усложняется ещё и тем, что многие зарабатывают на этом хайпе. В итоге чтобы найти реально полезные вещи приходится сначала наступить на много граблей. Я описал реальную ситуацию — огромный проект с большим легаси, чтобы развиваться пришлось начать многое изменять (что-то из этого получилось, что-то нет). Надеюсь кому-то это подскажет решение их проблем и получится пройти наш путь проще и быстрее.
Спасибо за статью, познавательно, есть что вспомнить)
А по поводу недалекого будущего, думаю все больше люди станут переходить с привычных хостингов на разного рода saas, paas и т.д.
Эта тенденция уже сегодня хорошо просматривается, возможно из-за этого обычный хостинг и перестал так стремительно, как раньше, падать в цене. Думаю, что в будующем vds и vdc хостинг будет интересовать в основном средний бизнес, которому нужна надежная инфраструктура, но не целесообразно её создавать самостоятельно.
Это в ходе экспериментов так выключал/включал дополнительные проверки в попытках ускорить сборку, а обратно для статьи поменять забыл.
1. Хотелось ускорить сборку проекта. Уже давно следим за новостями по Webpack 4. В этом видео Sean Larkin рассказывает подробнее. Angular 6 по-умолчанию использует Webpack 4 поэтому решили обновлять совместно. В итоге сейчас проект стал собираться на 40 секунд быстрее (думаю можно будет еще ускорить, но уже приятно).
2. С каждым обновлением команда Angular вносит ряд изменений в фреймворк, которые требуют переработки компонентов. Если затягивать с обновлением, то потом придется менять слишком много кода. Даже в update.angular.io если указать переход через несколько мажорных версии они напишут предупреждение: