Что нужно для перехода от серверного рендеринга к пользовательскому? Чем хорош Angular 2+ и как на него перейти? В этой статье попытаемся разобраться в данных вопросах и описать процесс миграции от серверных технологий рендеринга, таких, как JSP, к клиентским технологиям рендеринга представлений с использованием Angular.

Используемые технологии

Прежде чем приступить к коду, опишем весь стек используемых технологий:

• Spring Framework - фреймворк для Java-платформы.

• JSP - технология, позволяющая создавать содержимое, которое имеет как статические, так и динамические компоненты. Страница JSP содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов (например, HTML) и JSP-элементы. Эти элементы конструируют динамическое содержимое, позволяя внедрять Java-код в статичное содержимое страницы.

• AngularJS и Angular - JavaScript-фреймворки от компании Google для создания клиентских приложений. AngularJS был одним из первых JavaScript-фреймворков, разработанным для создания одностраничных приложений (SPA). Он был выпущен в 2009 году как фреймворк с открытым исходным кодом. В 2016 году был выпущен Angular 2. Он был переписан с нуля на TypeScript и не является обратно совместимым с AngularJS.

Изначально у нас есть приложение, написанное на Spring+JSP с использованием AngularJS.Наша цель - перейти к SPA с использованием современной версии Angular.

Какие перспективы?

Angular является современным и популярным фреймворком и обладает рядом преимуществ по сравнению с JSP и AngularJS.

Основное концептуальное различие между JSP и Angular заключается в том, динамически ли генерируется страница в браузере (на стороне клиента) или на сервере. При использовании Angular не приходится извлекать всю страницу с сервера после ее загрузки в первый раз. Вы просто обновляете части страницы, которые изменились на клиенте (хотя это часто происходит в ответ на данные, полученные с сервера). Рендеринг на стороне клиента позволяет избежать ненужных запросов на полную страницу, когда изменилась только ее часть.

Внедряем технологию

Перейдем непосредственно к описанию процесса перехода и рассмотрим вопросы, возникающие при смене технологий.

Инициализация нового Angular приложения

Вместо JSP-страниц нам теперь понадобится Angular приложение. Для его создания удобно использовать Angular CLI. Angular CLI - официальный инструмент для инициализации и работы с Angular-проектами. Он упрощает создание приложения, его компиляцию.

Angular CLI можно установить, выполнив следующую команду:

npm install @angular/cli

После создадим новый Angular проект с помощью команды:

ng new <название проекта>

Команда ng new генерирует скелет будущего приложения. Angular CLI создает одноименную директорию и помещает в нее исходные файлы "скелета" приложения.

Создание служебных сервисов

На JSP-страницах использовалась информация, содержащая Java-выражения, а также специфичные теги: http://www.springframework.org/tags, в частности, для локализации и http://java.sun.com/jsp/jstl/core. Также в некоторых ситуациях может существовать необходимость в кастомизируемом ролевом доступе, информацией о котором, помимо сервера, должен владеть и клиент. Для получения этой информации создадим дополнительные контроллеры с методами, возвращающими нужную информацию. Запросы, возвращающие сообщения для локализации, должны быть доступны без аутентификации. Это связано с тем, что эти сообщения отображаются на всех страницах, включая доступные неавторизованным пользователям. Поправим конфигурацию Spring Security, чтобы она игнорировала запросы по шаблону "/messages/*":

@Overridepublic void configure(WebSecurity web) {    web.ignoring().antMatchers("/messages/*");}

Для того, чтобы использовать эти данные, на фронтенде должны быть заранее известны коды сообщений и названия привилегий. Совпадение информации на фронтенде и бэкенде приходится отслеживать вручную.

Проксирование

В случае, когда клиент хостится на отдельном сервере, возникает потребность в проксировании запросов. Тот факт, что фронтенд и бэкенд прослушивают отдельные порты, не позволяет Angular делать внутренние запросы. Это связано с тем, что веб-браузеры разрешают только внутренние запросы к тому же источнику, из которого было загружено веб-приложение. К счастью, мы можем позволить Angular CLI выступать в качестве прокси-сервера для нашего бэкенда Spring. Приложение Angular будет отправлять бэкенд-запросы на сервер разработки, который будет пересылать их на бэкенд.

Для этого добавим в корневую папку проекта файл proxy.conf.json с конфигурацией прокси-сервера:

{  "/api": {    "target": "http://localhost:8099",    "secure": false,    "cookieDomainRewrite": "localhost",    "changeOrigin": true  }}

Также поправим package.json, чтобы данная конфигурация применялась, указав в стартовом скрипте "start": "ng serve --proxy-config proxy.conf.json".

Перенос JSP страниц в компоненты Angular

Angular приложение состоит из компонентов, у каждого из которых своя независимая логика. Компонент - полноценная сущность, у которой есть своя логика TypeScript, разметка HTML и свой стиль CSS. Соответственно каждая JSP-страница будет разбиваться на отдельные компоненты, в которых в отдельные файлы выносится html, typescript и css. Для отправки запросов к бэкенду создадим отдельные сервисы. Заменим конструкции AngularJS на аналогичные в Angular.

В каждом компоненте, в методе ngOnInit пропишем получение необходимых сообщений для локализации, а также добавим проверку наличия необходимых для данного компонента привилегий.

При открытии JSP-страницы выполняется проверка на наличие привилегий. В случае отсутствия привилегий пользователь перенаправляется на страницу входа.

<%   if (!SecurityUtils.hasRole(SecurityConstants.VIEW_USER)) {       response.sendRedirect("login.jsp");   }%>

В Angular есть механизм ограничения перехода, называемый Guards. Guards позволяют ограничить доступ к маршрутам на основе определенного условия.

Все guard-ы должны возвращать либо true, либо false. И происходить это может как в синхронном режиме (тип Boolean), так и в асинхронном режиме (Observable<boolean> или Promise<boolean>). Данный пример разрешает переход при наличии у пользователя привилегии VIEW_SETTINGS. Метод hasPrivilege отправляет запрос на сервис и возвращает Observable<boolean>.

@Injectable({ providedIn: 'root'})export class SettingsGuard { readonly  SECURITY_CONSTANTS = SecurityConstants; constructor(private router: Router,             private securityConstantService: SecurityConstantService) { } canActivate(next: ActivatedRouteSnapshot, state: RouterStateSnapshot):   Observable<boolean|UrlTree> | Promise<boolean|UrlTree> | boolean|UrlTree {   return this.securityConstantService.hasPrivilege(this.SECURITY_CONSTANTS.VIEW_SETTINGS); }}

Обработка ошибок

Следующий шаг - обработка ошибок, возвращаемых сервером. Добавим HttpInterceptor, который обеспечивает перехват http-запросов и ответов для преобразования или обработки их перед передачей. При получении ошибок 401 или 403 будем перенаправлять пользователя на страницу входа:

public handleError(err: HttpErrorResponse): Observable<any> {  if (err.url != null && (err.status === 401 || err.status === 403)) {    this.router.navigate(['/login']);  }  return throwError(err.error);}

Подобным образом можно обрабатывать другие ошибки, подробнее можно почитать, например, здесь.

Кэширование

Сообщения для локализации интерфейса, а также ряд других констант не меняется во время использования приложения, поэтому нет смысла каждый раз запрашивать их с сервера. Для реализации кэширования добавим RequestCache и CachingInterceptor.

RequestCache - сервис, который содержит методы, позволяющие добавлять информацию в кэш и извлекать ее из него. Вариантом реализации может послужить хранение данных в виде пар "ключ/значение", где ключом является название сообщения.

cache = new Map<string, RequestCacheEntry>();get(req: HttpRequest<any>): HttpResponse<any> | undefined {   const url = req.url + req.body.key;   const cached = this.cache.get(url);   if (!cached) {     return undefined;   }   const isExpired = cached.lastRead < (Date.now() - maxAge);   return isExpired ? undefined : cached.response; }put(req: HttpRequest<any>, response: HttpResponse<any>): void {   const url = req.url + req.body.key;   const newEntry = { url, response, lastRead: Date.now() };   this.cache.set(url, newEntry);   const expired = Date.now() - maxAge;   this.cache.forEach(entry => {     if (entry.lastRead < expired) {       this.cache.delete(entry.url);     }   }); }

CachingInterceptor реализует интерфейс HttpInterceptor, перехватывает запросы и решает, нужно их кэшировать или нет. Любой класс, реализующий интерфейс HttpInterceptor, должен иметь метод intercept.

В этом методе мы сначала проверим, нужно ли кэшировать данные из запроса (метод isCacheable), и, если нужно, попробуем извлечь данные из нашего кэша. Если у нас есть кэшированные данные для конкретного запроса, то мы вернем Observable с этими данными. Иначе мы отправим запрос на сервер для извлечения данных, в нашем случае, используя метод sendRequest. Этот метод также кэширует запрос для дальнейшего использования.

intercept(req: HttpRequest<any>, next: HttpHandler) { if (!isCacheable(req)) { return next.handle(req); } const cachedResponse = this.cache.get(req); if (req.headers.get('x-refresh')) {   const results$ = sendRequest(req, next, this.cache);   return cachedResponse ?     results$.pipe( startWith(cachedResponse) ) :     results$; } return cachedResponse ?   of(cachedResponse) : sendRequest(req, next, this.cache);}

Заключение

Итак, описанные действия приблизили нас к получению современного Angular приложения, совместимого с нашим бэкендом. Остальное было делом техники. Популярные фреймворки предоставляют широкий спектр возможностей и огромное комьюнити с поддержкой. Уход от устаревших технологий необходим для полноценного развития приложения, даже если переход может вызвать сложности. Надеюсь, эта статья поможет вам продвинуться в нужном для вас направлении.

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

Компании Holyweb, которая специализируется на аутстаффинге ИТ-персонала, стало интересно, что стоит за этими цифрами. Они решили задать вопросы непосредственно тому, кто принимает такие решения руководителю разработки на стороне клиента.

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

Стоит ли бояться, что подрядчик выйдет из проекта или заберет половину команды?

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

Страха, что подрядчик уйдет и кого-то заберет с собой, у нас нет. Этого стоит опасаться, если аутстафф-команда основная или вообще единственная часть разработки. Иными словами, когда у вас либо нет собственных разработчиков, либо их меньшинство и они выполняют только поддерживающую функцию.

Совет тут один: не складывайте все яйца в одну корзину, работайте с разными поставщиками. В конце концов, люди могут исчезнуть просто потому, что поставщик аутстафф-услуг обанкротился, и вы на это никак не повлияете.

Кажется, что работать с одним подрядчиком удобнее, чем с несколькими сразу ты уже видел людей в деле, знаешь на что они способны и доверяешь им. Но ты не можешь управлять внешними факторами, поэтому необходимо диверсифицировать риски.

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

Как строить долгосрочные отношения с поставщиком и его командой? Опираясь на наш опыт, могу сказать, что внешнюю команду нужно тщательно встроить в рабочий процесс и обучать, так же как и собственных сотрудников. Для разработчиков это будет полезным опытом, а подрядчику мы таким образом показываем серьезные намерения и желание работать вдолгую и можем рассчитывать на то, что они заложат резервные ресурсы на случай форс-мажора.

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

Отношение внутренней команды разработчиков к аутстафферам может серьезно сказаться на продолжительности сотрудничества. Важно отслеживать, как они взаимодействуют. Момент притирки внешних и внутренних команд очень важный мы тоже это проходили и в каком-то смысле до сих пор привыкаем друг к другу, хотя и работаем вместе с внешними членами команды довольно давно. У меня не было откровенно негативного опыта, но я могу представить, что в некоторых ситуациях действительно могут возникнуть трудности.

Например, саботаж со стороны внутренних разработчиков, причиной которому может стать банальная ревность. Представьте: команда месяцами или годами пилит продукт, и вдруг приходят разработчики со стороны и начинают предлагать новые идеи, добавляют свой код (и критикуют существующий), требуют к себе внимания. Главное здесь заранее донести до команд всю ценность их взаимодействия и убедиться, что все одинаково понимают общие цели. И, конечно, не пускать взаимоотношения на самотек, а держать их под контролем и вовремя реагировать на тревожные звоночки.

Еще противоречие, которое может привести к конфликту, команда внутренних разработчиков ориентирована на стабильность и долгосрочное развитие сервиса, а аутстафф-команда, наоборот, заточена на скорость доставки новых фичей здесь и сейчас. Разрешить его можно правильной постановкой задач и едиными требованиями к разработке.

Очень важно, чтобы все понимали задачи друг друга. Конечно, синхронизироваться за неделю не получится это долгий процесс, и к этому нужно быть готовым.

Например, мы делали несколько подходов с кросс-приемкой работ и постоянным ревью кода, много раз проговаривали особенности архитектурного подхода.

Как доверять, но проверять?

Универсальный совет выделите сотрудника, который следит за загрузкой специалистов и администрирует всю работу аутстафф-команды.

Но, честно говоря, не думаю, что стоит внедрять специальные практики для контроля над внешними сотрудниками. Есть ключевые параметры цена, качество кода и скорость работы. Меня, как заказчика, волнует, сколько денег я потратил и что за них получил.

Если для эффективной работы программисту нужно играть на балалайке или в Dota пожалуйста. Оценивать мы будем результат.

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

Мотивация зависит от множества факторов, в том числе от микроклимата во внешней команде, наличия переработок и в целом от того, как выстроены бизнес-процессы в компании-поставщике. Поэтому важно на этапе подбора подрядчика оценить не только скиллы отдельных специалистов, но и общую атмосферу в компании.

При правильной организации процессов и хорошем онбординге вовлеченность и мотивация аутстфферов сопоставима с мотивацией штатного специалиста.

Если проблемы с мотивацией внешней команды все-таки возникают, нужно незамедлительно общаться с руководителем команды со стороны поставщика.

Нам приходилось менять как компании-подрядчиков, так и самих специалистов внутри проекта, если они не подходили нам по софт-скиллам. Под ними я, в том числе, понимаю возможность самостоятельно выполнять задачи и давать качественную обратную связь о проблемах на проекте.

Когда можно делать первые выводы об эффективности аутстафферов? Первый месяц работы самый важный?

Оценка эффективности зависит от того, работает специалист внутри нашей команды или речь идет о полностью внешней выделенной команде.

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

Как правило, первый месяц работы не всегда дает объективную картину по эффективности. Разработчик на аутстаффе должен полностью погрузиться в предметную область, внутренние рабочие процессы спринты, планирование, груминг бэклога, созвоны и обсуждения корпоративную культуру и атмосферу заказчика.

При оценке внешней команды мы смотрим на ее результативность. Качество коммуникации можно оценить уже в начале работы. Через 2-3 недели становится понятно, насколько аутстафферы проактивны, самостоятельно инициируют обратную связь или нет, сразу ли сообщают о возникшей проблеме, предлагая собственные пути решения.

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

Мы проводим полноценное техническое интервью такое же, как для сотрудников Mail.ru Cloud Solutions, которых берем в штат. Обязательно уделяем внимание софт-скилам разработчика и его кругозору. Кроме того, устраиваем собеседование с руководителем команды и продуктовым менеджером.

Этапы отбора не отличаются для аустафферов и членов инхаус-команды, ведь требования и для тех, и для других у нас одинаковые.

Важно обсудить видение и требование к подходам, ожидания от результатов работы, а после того, как специалист попал в команду, грамотно провести процесс онбординга без этого качественный результат не получить.

Аутстаффинг относительно новая форма взаимоотношений между клиентом и поставщиком, и правила игры только формируются. Если тема вас заинтересовала, рекомендуем почитать другие статьи Holyweb об аутстаффинге: почему это выгодно и как успешно обходить подводные камни.

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

Привет, Хабр!

Одним из наиболее популярных направлений разработки сегодня является веб. И когда нужно разместить свой проект где-нибудь, кроме localhost, многие сталкиваются с трудностями - ведь хостинг должен быть быстрым, удобным, и, желательно, бесплатным :)

В этом списке вы найдете 15 бесплатных сервисов, где легко сможете разместить свой проект и не заплатите ни копейки. Погнали!

Vercel

Данный сервис позволяет собирать и размещать статические веб-сайты на различных фреймворках (поддерживаются как JS-фреймворки, так и, например, генераторы статических сайтов - Hexo, Hugo, Jekyll и другие). Для каждого проекта выделяется несколько бесплатных доменных имен третьего уровня, есть возможность предпросмотра сборки.

Вот что включает в себя бесплатный тариф:

• 50 пользовательских доменов

• 100 Гб файлового пространства

• 100 Гб ежемесячного трафика

• Неограниченное количество проектов

• CLI-интерфейс

• Serverless, CDN, CI/CD

Netlify

Netlify - прямой конкурент Vercel. Однако, кроме функций, которые предоставляет предыдущий сервис, тут на бесплатном тарифе присутствует:

• Обработка до 100 отправленных форм в месяц

• До 1000 авторизованных пользователей в месяц

• Аналитика работы сайта

Heroku

Heroku позволяет запускать Full Stack приложения в контейнерах (так называемых Dynos). Поддерживается большое число языков программирования и фреймворков. Главный недостаток - после получаса бездействия проекты, размещенные на бесплатном тарифе, "засыпают", а повторный запуск контейнера требует определенного времени.

На стартовом тарифе доступны:

• 550 часов/месяц работы Dynos (1000 после привязки банковской карты)

• 512 Мб ОЗУ на 1 контейнер

• CI/CD, CLI

• По 1 домену на 1 контейнер

Stormkit

Stormkit позволяет размещать только проекты на JavaScript. Бесплатно доступны:

• 1 проект

• 50 Гб трафика

• Неограниченное количество доменов

• Неограниченное количество сборок

Hostman

Полноценный хостинг с поддержкой бэкенда и баз данных. Однако бесплатный тариф позволяет разместить до 10 веб-сайтов, и то статических:

• 100 Гб/месяц трафика

• Бесплатные домены и SSL

• CI/CD, CDN

Glitch

Glitch позиционирует себя как коллаборативный сервис для упрощенной разработки веб-сайтов. В основном здесь находятся проекты на NodeJS, но поддерживается ряд других языков. Приложения запускаются в контейнерах, как на Heroku, и тут так же доступно 1000 бесплатных часов работы приложений в месяц. Однако, если на Heroku проекты заливаются через CLI или Git, здесь присутствует браузерная IDE и терминал.

Repl.it

Подобен предыдущему сервису. Бесплатно предоставляется 0.5 Гб ОЗУ и 0.5 Гб дискового пространства.

Surge

Хостинг статических сайтов. Бесплатно доступны:

• 1 сайт с 1 доменом третьего уровня

• Неограниченное количество сборок

Firebase

PaaS-сервис от Google, позволяющий разработать бэкенд без написания кода, а также разместить свой статический веб-сайт. Вот что входит в стартовый тариф:

• 10 Гб дискового пространства

• 360 Мб трафика/день

• Базы данных

• Serverless

• Тестирование

• Многое другое

Render

Сервис для размещения статических веб-сайтов. Бесплатно доступны:

• 100 Гб трафика в месяц

• CDN, CI/CD, SSL

GitHub Pages

С помощью этого инструмента из любого репозитория GitHub можно развернуть статический веб-сайт. Поддерживается Jekyll, доступен 1 бесплатный домен 3 уровня, SSL, неограниченный трафик.

begin

Хостинг для практически любых веб-приложений на NodeJS или Deno. Бесплатно доступно 5 веб-сайтов, поддерживается Serverless.

Deta

Достаточно интересный проект, предоставляющий возможность размещения веб-приложений на Python и NodeJS. К каждому приложению подключается NoSQL база данных. Главный минус - все взаимодействие с сервисом осуществляется через CLI. Бесплатно доступны:

• 2 Гб дискового пространства, 2 Гб на базу данных

• 50 000 обращений к контейнерам в месяц

• 25 000 обращений к БД в месяц

Fly

Очередной сервис, позволяющий запускать приложения в виртуальных машинах. Со стартовым тарифом вы получите:

• 8 миллионов секунд работы VM в месяц (хватит примерно на 3 VM, запущенных постоянно)

• 160 Гб ежемесячного трафика

• 10 активных SSL-сертификатов

Fleek

Позволяет размещать статические сайты, перед этим собирая их на ряде генераторов статических сайтов (если нужного нет в списке, можно выбрать Docker-образ, в котором будет осуществляться сборка, и указать все данные для нее). Бесплатный тариф имеет следующие ограничения:

• 3 Гб дискового пространства

• 50 Гб ежемесячного трафика

• 250 минут на сборку в месяц

Заключение

На этом подборка бесплатных хостингов заканчивается. Надеюсь, вы уже нашли себе подходящий вариант и готовы разместить свое приложение.

Буду рад, если вы предложите свои варианты - достойные сервисы будут также внесены в этот список.