Комментарии 19
Проблемы, решение которых вы описываете в статье, были характерны для старых шаблонов, созданных еще для .NET Core 1.0. Команда ASP.NET Core хорошо поработала, теперь client не прибит гвоздями к серверу, рекомендую использовать template от команды asp.net. Можно использовать angular-cli. А вся необходимая настройка состоит из пары строк:
Вся магия в пакете Microsoft.AspNetCore.SpaServices.Extensions
context.UseSpaStaticFiles();
context.UseSpa(spa =>
{
if (env.IsDevelopment())
{
spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");
}
});
Вся магия в пакете Microsoft.AspNetCore.SpaServices.Extensions
Спасибо за совет! Однако упоминаний про это расширение я ни разу не встретил, когда пытался разобраться с темой. Надеюсь, что этот вариант удобнее и еще проще того, что я описал. Посмотрю.
Вот документация: https://docs.microsoft.com/en-us/aspnet/core/spa/angular (если ссылка перестанет работать, вот еще одна)
В целом эта штука повторяет тоже самое, что я и описал в посте:) Единственные различие, что сам app находится внутри .NET Core проекта и простая настройка занимает чуть больше строк кода.
Расскажите, в чем профит вообще этого шаблона, кроме того что создается все одной командой? Пока на первый взгляд ничего существенно полезного не увидел.
Расскажите, в чем профит вообще этого шаблона, кроме того что создается все одной командой? Пока на первый взгляд ничего существенно полезного не увидел.
Создание одной командой уже само по себе неплохо. Для меня главное
преимущество — возможность использовать стандартную cookie-based авторизацию из asp.net core identity. Плюс возможность делать так:
Страницы авторизации и оплаты — это asp.net вьюхи — можно не переживать за кражу паролей и кредитных карт с помощью внедрения зловредного кода в node_modules (проверить все зависимости, которые тащит за собой ангуляр, а тем более сторонние модули просто невозможно). Плюс не авторизованный пользователь даже не получит кода нашего клиентского приложения.
Второй плюс — ноль самодельных костылей, которые надо потом поддерживать, все используемые функции — часть проекта ASP.NET Core и поддерживаются его командой.
преимущество — возможность использовать стандартную cookie-based авторизацию из asp.net core identity. Плюс возможность делать так:
app.UseWhen(context => context.User.Identity.IsAuthenticated, context =>
{
context.UseSpaStaticFiles();
context.UseSpa(...);
}
Страницы авторизации и оплаты — это asp.net вьюхи — можно не переживать за кражу паролей и кредитных карт с помощью внедрения зловредного кода в node_modules (проверить все зависимости, которые тащит за собой ангуляр, а тем более сторонние модули просто невозможно). Плюс не авторизованный пользователь даже не получит кода нашего клиентского приложения.
Второй плюс — ноль самодельных костылей, которые надо потом поддерживать, все используемые функции — часть проекта ASP.NET Core и поддерживаются его командой.
Поставил бы плюс, если бы мог:) Спасибо, за разъяснение.
У вас нет случайно ссылок на гитхаб или статьи, где есть такое «смешивание» asp.net view и angular страниц? Как сделать страницу авторизации и перекинуть потом в приложение понимаю. Но как внедрить страницу оплаты — что-то не очень. Единственное, что пока приходит в голову — это просто перенаправлять с приложения на отдельную страницу. Существуют варианты, как подгружать вьюхи внутрь Angular приложения?
У вас нет случайно ссылок на гитхаб или статьи, где есть такое «смешивание» asp.net view и angular страниц? Как сделать страницу авторизации и перекинуть потом в приложение понимаю. Но как внедрить страницу оплаты — что-то не очень. Единственное, что пока приходит в голову — это просто перенаправлять с приложения на отдельную страницу. Существуют варианты, как подгружать вьюхи внутрь Angular приложения?
Не видел таких проектов на гитхабе, я знаю только один boilerplate с авторизацией, но там все сделано на клиенте, с другой стороны переделывать совсем немного.
Нужно, чтобы маршруты в angular router не совпадали с маршрутами в asp.net, а потом при переходе на страницу с url, которого angular не знает он сделает запрос на сервер и пользователь увидит нужную страницу. Я не встраиваю эти вьюхи в приложение в своём проекте, но это легко можно сделать с помощью iframe.
Нужно, чтобы маршруты в angular router не совпадали с маршрутами в asp.net, а потом при переходе на страницу с url, которого angular не знает он сделает запрос на сервер и пользователь увидит нужную страницу. Я не встраиваю эти вьюхи в приложение в своём проекте, но это легко можно сделать с помощью iframe.
Было бы интересно также прочитать про миграцию приложений, построенных «старым способом», на новый, описанный в статье или, как выше указали, в шаблонах)
Интересуют подводные камни и стоит ли вообще игра свеч)
Интересуют подводные камни и стоит ли вообще игра свеч)
В сущности, никакой миграции не нужно. Всего 3 шага:
1. Устанавливаем Microsoft.AspNetCore.SpaServices и Microsoft.AspNetCore.SpaServices.Extensions
2. Правим конфигурацию в Startup.cs
3. Создаём и настраиваем .angular-cli.json
Всё описано в документации.
Если до этого использовали webpack с хитрой конфигурацией, могут возникнуть трудности из-за того, что angular-cli на даёт такой гибкости. Да, можно извлечь weback.config из angular-cli, но это строго не рекомендуется разработчиками angular.
В моём проекте обновление того стоило. Содержать webpack.config.dev.js и webpack.config.prod.js больше не нужно — это экономит кучу времени.
Правда есть недостатки, с помощью angular-cli невозможно (пока) убрать локали moment.js из бандла. А это лишние 300 Кб.
1. Устанавливаем Microsoft.AspNetCore.SpaServices и Microsoft.AspNetCore.SpaServices.Extensions
2. Правим конфигурацию в Startup.cs
3. Создаём и настраиваем .angular-cli.json
Всё описано в документации.
Если до этого использовали webpack с хитрой конфигурацией, могут возникнуть трудности из-за того, что angular-cli на даёт такой гибкости. Да, можно извлечь weback.config из angular-cli, но это строго не рекомендуется разработчиками angular.
В моём проекте обновление того стоило. Содержать webpack.config.dev.js и webpack.config.prod.js больше не нужно — это экономит кучу времени.
Правда есть недостатки, с помощью angular-cli невозможно (пока) убрать локали moment.js из бандла. А это лишние 300 Кб.
А теперь стоит вспомнить про SEO и Angular Universal и снова сменить архитектуру приложения. Либо на Node.Js -> Angular, либо интегрировать в Asp.Net Core. Таким образом ни одно из представленных решений не сможет нам помочь :)
Все знают, что ситуация с SEO для SPA приложений не очень хорошая. Но особого смысла делать SPA для обычного лендинга или сайта компании/продукта/итд нет. Single Page подход используются преимущественно именно для веб-приложений с широкой функциональностью. На мой взгляд, до тех пор пока Google не научится нормально индексировать одностраничные приложения, лучше сделать обычный лендинг по вашему продукту, а само приложение размещать отдельно, например на поддомене.
Что касается Server-Side Rendering. С такой архитектурой не прокатит, верно. Но если вы хотите использовать его, чтобы увеличить производительность, то можно попробовать поэкспериментировать с Lazy Loading и настроить .NET Core под это дело. Признаюсь, я не пробовал. Но кейс интересный — проверю.
Что касается Server-Side Rendering. С такой архитектурой не прокатит, верно. Но если вы хотите использовать его, чтобы увеличить производительность, то можно попробовать поэкспериментировать с Lazy Loading и настроить .NET Core под это дело. Признаюсь, я не пробовал. Но кейс интересный — проверю.
SSR как раз таки главным образом и используют для того, чтоб можно было сгенерировать полноценную отрендеренную страницу и скормить её ботам поисковиков, но не для ускорения, его то как раз таким образом не достичь, ведь интерфейс быстрее не проинициализируется.
Для ускорения как раз подойдёт, как вы уже заметили, LazyLoading и (частично не актуально начиная с 6й версии ангуляра) грамотное расставление импортов.
Если вы приведете примеры действительно оправданного использования Single Page для веб-сайтов, которые нужно индексировать, то я соглашусь с тем, что такой вариант не очень и поменяю свою мнение:) Пока я лично считаю, что SPA не нужно использовать повсеместно. А там, где его использование необходимо, то индексация поисковиком и SEO оптимизация отходит на второй план.
На asp.net core SSR в angular работает из коробки, просто нужно его включить. Выше я привел ссылку на документацию, если интересно как оно работает.
Не важно на чем написан API, даже если это сторонний сервис. Node в проде тут выступит как прокси (без всякого отношения к бекенду или самому Angular-приложению), который соберет данные с нужных эндпоинтов и отрендерит html.
Node участвует, главным образом, как среда выполнения js-кода :)
а так да, в случае Node.js+angular обычно используется express, в случае asp net core — NodeServices, вроде как (а под капотом поднимается процесс ноды и она всё обрабатывает и возвращает вёрстку готовую).
просто под ASP.NET Core + angular ещё ведь обычно предполагается, что будут использовать всякие razor helpers, передачу данных из controller-а во вьюхи и т.д., чтоб использовать эту связку по максимуму.
или я не прав где-то?
а так да, в случае Node.js+angular обычно используется express, в случае asp net core — NodeServices, вроде как (а под капотом поднимается процесс ноды и она всё обрабатывает и возвращает вёрстку готовую).
просто под ASP.NET Core + angular ещё ведь обычно предполагается, что будут использовать всякие razor helpers, передачу данных из controller-а во вьюхи и т.д., чтоб использовать эту связку по максимуму.
или я не прав где-то?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткое руководство: связываем ASP.NET Core Web API + Angular 5