Введение
Цифровая трансформация с каждым годом охватывает все больше различных сфер жизни и бизнеса. Если бизнес хочет быть конкурентоспособным обычных информационных сайтов уже недостаточно, необходимы мобильные и веб-приложения, которые не просто дают пользователям информацию, но и позволяют выполнять какие-то функции: получать или заказывать товары и услуги, предоставлять инструменты.
Так, например, современным банкам уже недостаточно иметь сайт с информацией, необходимо иметь онлайн инструменты для своих клиентов, личный кабинет, где пользователь может управлять счетами, инвестициями, кредитами. Даже малому бизнесу, для повышения конверсии, необходимы удобные инструменты, например запись на прием к врачу или парикмахерскую, бронирование столика в ресторане или детской игровой комнаты для проведения дня рождения.
А самим владельцам нужно своевременно получать информацию в удобном виде по состоянию своей компании, например, сбор статистических данных и аналитики по разным отделам производств, или производительность отделов. Часто каждый из отделов, по-своему собирает эти данные, и даже могут использовать разные инструменты и владельцу нужно тратить много личного времени, чтобы разобраться во всем этом, косвенно или прямо это может влиять на эффективность компании и в конечном счете на прибыль. Тут тоже поможет цифровая трансформация и разработка веб- или мобильного приложения.
Технологии не стоят на месте и постоянно развиваются, и то, что использовали несколько лет назад уже может быть неактуально сегодня, или то что не могли сделать несколько лет назад уже стало реальностью. Существует больше количесто современных инструментов, которые помогают создавать веб- и мобильные приложения быстрее и качественней. Основываясь на личных наблюдениях и опыте, хочу поделиться своим видением, какие из технологий и инструментов будут востребованы в ближайшее время и почему на них стоит обратить внимание при создании современного веб-приложения.
Single page application (одностраничные приложения)
Давайте немного определимся с терминологией. Single Page Application (SPA) – это веб-приложение, компоненты которого загружаются единожды на одной странице, а контент подгружается по необходимости. И при переходе между разделами приложения страница не перезагружается полностью, а только подгружается и отображаются необходимые данные.
Одностраничные приложения сильно выигрывают по скорости работы и удобству использования у классических web-приложений. При помощи SPA можно добиться эффекта работы вебсайта, как приложения на десктоп, без перезагрузок и существенных задержек.
Если несколько лет назад одностраничные приложения практически не поддерживали поисковую оптимизацию и их использовали преимущественно для создания личных кабинетов и панели администрирования, то сегодня создать одностраничное приложение с полной поддержкой поисковой оптимизации (SEO) стало намного проще. Используя одностраничные приложения с серверным рендерингом сегодня эта проблема полностью исчезла. Другими словами, это такое-же одностраничное приложение, но при первом запросе, сервер генерирует не просто данные, а создает готовую для отображения HTML страницу и поисковые системы получают готовые страницы со всей мета-информацией и семантической разметкой.
C развитием инструментов создания клиентский веб-приложений, разработка и переход на одностраничные приложения в этом и последующих годах будут только расти. Если у вас старое приложение, которое морально устарело и работает медленно, да еще с полной перезагрузкой страницы при переходе между разделами, то в этом году можете смело обновляться на быстрое одностраничное приложение – сейчас хорошее время, технологии уже позволяют это сделать довольно быстро и качественно.
Иметь современный и быстрый веб-сайт это очень хорошо, но хочу честно вам сообщить: не все приложения можно легко перевести в одностраничные, и переход может обойтись недешево! Поэтому нужно понимать, кому и зачем нужен такой переход.
Чтобы помочь вам разобраться, в таблице ниже я приведу несколько примеров, когда разработка или переход на SPA уместны и обоснованы, а когда нет.
| ЗА |
| Если вы хотите сделать современное, быстрое приложение и хотите, чтобы пользовались не только веб-версией, но и мобильной или даже десктопной, а все процессы и вычисления происходили на удаленном или облачном сервере. Да еще и так, чтобы все клиенты имели один интерфейс взаимодействия и не было необходимости вносить каждый правки в серверный код при добавлении нового клиента. Например: социальная сеть, агрегаторы, SaaS платформы(программное обеспечение как облачная услуга), маркетплейсы |
| Если у вас есть магазин или веб-сервис, вы знаете что он медленный и люди уходят, хотите сделать более быстрым, понимаете ценность клиентов и готовы заплатить за апгрейд от миллиона рублей. |
| У вас есть мобильное приложение, которое использует API сайта, а сайт при этом медленный и с полными перезагрузками контента при переходе между страницами |
| ПРОТИВ |
| Если ваша целевая аудитория не использует современные браузеры и девайсы. Например: специфические корпоративные сферы, такие как разработка внутренних систем для банков, медицинских учреждений и образования. |
| Основную деятельность вы ведете в офлайне и не готовы предоставлять какие-либо услуги онлайн, и вам нужно просто привлечь клиентов. |
| Если у вас существует интернет-магазин или веб-сервис, который и так хорошо продает, вы не видите оттока клиентов и жалоб |
| Если у вас есть рабочее приложение, которое невозможно адаптировать под SPA и нужно просто все переписывать с нуля и использовать другие технологии, а вы не готовы потратить на это несколько миллионов. Например: Есть коробочный сайт или какой-то самописный древний, монолитный код. |
Progressive Web Applications
Progressive Web applications (прогрессивное веб-приложение) – это продукт совместной эволюции нативного приложения и веб-сайта. По сути это веб-приложение, которое выглядит и ведет себя как реальное нативное приложение, может получать пуш уведомления, работать в оффлайн-режиме и т.д. При этом пользователю не нужно скачивать приложение из AppStore или Google Play, а достаточно просто сохранить на рабочий стол.
Как технология или подход к разработке PWA развивается с 2015 года, а в последнее время еще и набирает огромную популярность в e-commerce сфере.
Несколько реальных примеров из жизни:
- в прошлом году отель Best Western River North после того, как запустил новый сайт с поддержкой PWA, смог увеличить выручку на 300%;
- арабский Авито OpenSooq.com после создания поддержки PWA на своем сайте смог увеличить на 25% время посещения сайта и на 260% количество лидов;
- известный сервис для знакомств Tinder смог уменьшить скорость загрузки с 11.91с до 4.69с разработав PWA, более того, приложение весит на 90% меньше своего нативного Android аналога.
О том, что стоит обратить внимание на эту технологию говорит и то, что один из самых крупных движков для создания e-commerce проектов Magento в 2018 году запустил раннюю девелоперскую версию PWA Studio. Платформа позволяет «из коробки» создавать фронтенд на базе React для своих e-commerce решений с поддержкой PWA.
Совет для тех, у кого уже есть интернет-проект или только идея нового сервиса с поддержкой мобильных устройств: не спешите писать полноценное нативное приложение, а сначала посмотрите на технологию PWA. Возможно это будет лучшее решение по соотношению цены и качества для вашего продукта.
Немного из практики. Чтобы создать простое нативное мобильное приложение новостей при условии, что уже есть готовый REST сервер, необходимо примерно 200-300 человеко-часов на каждую платформу. При средней цене по рынку за час разработки в 1500-2000 руб./час, приложение может стоить около 1 миллиона рублей. Если разрабатывать веб-приложение с полной поддержкой PWA: push уведомлениями, офлайн режимом и прочим плюшками, то разработка займет 200-300 человеко-часов, но продукт сразу будет доступен на всех платформах. То есть экономия примерно в 2 раза, не говоря уже о том, что не придется платить взносов для размещения в магазинах приложений.
Serverless
Это еще один современный подход к разработке. Из-за названия многие думают, что это действительно безсерверная разработка, писать back-end код не нужно, а любой фронтенд разработчик сможет сделать полноценное веб-приложение. Но это не так!
При создании Serverless-приложения сервер по-прежнему нужен и базы данных тоже. Основное отличие этого подхода в том, что back-end код представлен в виде облачных функций (другое название serverless – FaaS, функции как сервис или Functions-as-a-Service) и позволяет приложению быстро и легко масштабироваться. При создании такого приложения разработчик может сфокусироваться на бизнес-задачах и не думать о масштабировании и настройке инфраструктуры, что впоследствии ускоряет разработку приложения и снижает ее стоимость. Более того, Serverless подход поможет сэкономить на аренде серверов, так как он использует ровно столько ресурсов, сколько нужно для выполнения задачи, и если нет нагрузки, то серверное время вообще не используется и не оплачивается.
Например, крупная Американская медийная компания Bustle, смогла уменьшить расходы на хостинг более чем на 60% при переходе на Serverless. А компания Coca-cola, при разработке автоматизированной системы продажи напитков через автоматы, смогла уменьшить расходы на хостинг с $13000 до $4500 в год за счет перехода на Serverless.
Последние пару лет из-за новизны и своих ограничений Serverless в основном использовался для небольших проектов, стартапов и MVP, но сегодня, благодаря эволюции программного обеспечения, универсальности и мощности контейнеризации серверов, появляются инструменты, которые позволяют убрать ограничения, упростить и ускорить разработку облачных приложений.
Это означает, что корпоративные бизнес-сценарии, в которых облачная модернизация ранее считалась невозможной (например, для периферийных устройств, передаваемых данных или приложений с сохранением состояния), теперь является реальностью. Хорошими инструментами, подающими большие надежды, являются kNative и Serverless enterprise.
Но при всем этом, Serverless не является серебряной пулей для разработки веб-приложений. Как и любая другая технология она имеет свои достоинства и недостатки, и нужно с пониманием выбирать этот инструмент, а «не забивать гвозди микроскопом», только потому, что он технологичней.
Чтобы помочь вам разобраться, вот несколько примеров, когда стоит задуматься о Serverless при разработке нового или усовершенствовании текущего веб-сервиса:
- Когда нагрузка на сервер имеет периодичный характер и вы платите за простой мощностей. Например, у нас был клиент с сетью кофейных автоматов и необходимо было обрабатывать запросы и собирать статистику всего лишь несколько сотен или тысяч раз в день, а ночью количество запросов падало до нескольких десятков. В данном случае намного эффективней платить только за реальное использование ресурсов, поэтому мы предложили и реализовали решение на Serverless;
- Если вы не планируете погружаться в технические детали инфраструктуры и переплачивать за настройку и поддержку серверов и балансировщика. Например, при разработке маркетплейса вы точно не знаете какая будет посещаемость или наоборот — планируете большую посещаемость и чтобы ваше приложение наверняка выдержало нагрузку, то Serverless — отличный выбор.
- Если необходимо выполнять какие-то потоковые события в работе основного приложения, записывать побочные данные в таблицы, выполнять какие-то вычисления. Например, собирать аналитические данные действий пользователя, обрабатывать их определенным образом и сохранять в базу данных;
- Если нужно упростить, унифицировать или ускорить текущую работу приложения. Например, создать улучшающую производительность сервисы по работе с изображениями или видео, когда пользователь загружает видео, в облако, и транскодингом занимается отдельная функция, основной сервер при этом продолжает работать в штатном режиме.
Если нужно обрабатывать события со сторонних сервисов. Например, обрабатывать ответы от платежных систем, или перенаправлять пользовательские данные в CRM для ускорения обработки запросов потенциальных клиентов
Если у вас большое приложение и некоторые части приложения могут быть реализованы более оптимально, используя язык, отличающийся от основного. Например, у вас проект на Java и нужно добавить новый функционал, а свободных рук нет, или на данном языке реализация может занять большее время и есть уже решение на другом языке, то Serverless может помочь и в этом.
Это далеко не весь перечень инструментов и технологий, которые заслуживают внимания, я лишь поделился тем, что мы сами используем каждый день в работе и точно знаем, как они могут помочь бизнесу.
Комментарии (13)
noodles
14.05.2019 12:25Если несколько лет назад одностраничные приложения практически не поддерживали поисковую оптимизацию и их использовали преимущественно для создания личных кабинетов и панели администрирования
Считаю, что именно для этого их и стоит использовать, ни никак не для «контентных» сайтов или лендингов. Иначе получается, сами создаём себе проблемы (индексация, seo, роутинг, размер и разбиение бандла и т.д.), а потом героически их же и решаем.
И при переходе между разделами приложения страница не перезагружается полностью, а только подгружается и отображаются необходимые данные.
Одностраничные приложения сильно выигрывают по скорости работы и удобству использования у классических web-приложений.
Спорное утверждение. Какая разница, где наблюдать спиннер — во вкладке браузера, или в самом UI?
Используя одностраничные приложения с серверным рендерингом сегодня эта проблема полностью исчезла.
От уважаемых людей слышал, что на рынке пока нет человеческого решения для SSR, без ада и содомии для команды. Возможно, это уже не так.repjov Автор
14.05.2019 12:51Считаю, что именно для этого их и стоит использовать, ни никак не для «контентных» сайтов или лендингов. Иначе получается, сами создаём себе проблемы (индексация, seo, роутинг, размер и разбиение бандла и т.д.), а потом героически их же и решаем.
Конечно для лендингов это не имеет смысла, в статье я уделил внимание, когда имеет место быть SPA, а когда нет. Для блога, скорее тоже нет, чем да. А вот для магазина, вполне себе можно, просто пока нет широкораспространенных фреймверков или CMS для такой работы, и это сделать не дешево.
Спорное утверждение. Какая разница, где наблюдать спиннер — во вкладке браузера, или в самом UI?
Конечно разница есть, вместо того, чтобы рендерить страницу полностью, клиент получает только часть данных, и перерисовывает только их. Так же сервер не занимается лишними операциями по формированию html стрницы, что при большой посещаемости может существенно разгрузить сервер.
От уважаемых людей слышал, что на рынке пока нет человеческого решения для SSR, без ада и содомии для команды. Возможно, это уже не так.
Уже есть, и мы используем их каждый день в своей работе. Например, nextjs.org
noodles
15.05.2019 00:36А вот для магазина, вполне себе можно
Например, nextjs.org
В магазинах для продвижения самое чувствительное — это, пожалуй, карточка товара. Правильно оформленная… с заголовком h1, описанием, и с человеко-читаемым уникальным индексируемым роутом на каждый товар. Просто, на самом деле интересно — nextjs такое реально умеет?
Кстати:
Одностраничные приложения сильно выигрывают по скорости работы и удобству использования у классических web-приложений. При помощи SPA можно добиться эффекта работы вебсайта, как приложения на десктоп, без перезагрузок и существенных задержек.
Rozetka.com.ua, hotline.ua — в топах украинского поиска, абсолютно не стесняются перезагружать страничку на каждый товар, и ничего страшного. Фильтры, табы — там да, удобнееajaxspa прикрутить.Alexxosipov
15.05.2019 10:45Nuxtjs рендерит первую вьюху на сервере, в следствие этого любой сеошный робот будет это видеть полностью валидным html со всеми сео прелестями. Но вот вопрос, что стоит ли это делать для интернет-магазина? Мы получаем не только разделение бэкенда и фронтенда, но еще и отдельный проект с зависимостями от api. По метрике видел, что полностью идентичный сайт на SPA и MPA имеет полностью идентичные (в рамках разумной погрешности на 10к уников) показатели.
repjov Автор
15.05.2019 10:53В магазинах для продвижения самое чувствительное — это, пожалуй, карточка товара. Правильно оформленная… с заголовком h1, описанием, и с человеко-читаемым уникальным индексируемым роутом на каждый товар. Просто, на самом деле интересно — nextjs такое реально умеет?
Умеет, причем прекрсно. Next использует SPA SSR и на базе шаблонизатора React рендерит страницу на сервере и подготавливает приложение, отдает готовую страницу клиенту, и уже клиент запускает полноценное приложение и дальше работет как стандартное SPA
Rozetka.com.ua, hotline.ua — в топах украинского поиска, абсолютно не стесняются перезагружать страничку на каждый товар, и ничего страшного. Фильтры, табы — там да, удобнее ajax spa прикрутить.
Пусть себе перезагружают, никто не говорит что SPA это панцея, но при помощи нее можно добится более удобного интерфейса и взаимодействия с пользователем, расширить горизонты
Sunexpo
15.05.2019 08:41Более того, новые хромы позволяют использовать SPA как PVA без прикручивания инстанса браузера к последнему вручную. Делаешь SPA, при входе на него из нового хрома тот предлагает установить его как приложение со всеми вкусняшками типа пушей и прочего (Приложение будет использовать имеющийся в системе хром для своей работы). Это уже работает на андроиде. Скоро вроде как для всех платформ.
demimurych
16.05.2019 21:45Типичный пример материала, который наглядно показывает почему SEO специалистов не любят — из-за тотальной технической беграмотности.
Разберем на примере этой статьи,Технологические тренды веб-разработки 2019
Первый пункт.
Single page application
Первые SPA появились в 2006 году. С 2012 года, в силу того что все проблемы сопутствующие SPA были решены, это стал стандарт де факто для любой студии которая понимает как правильно делать сайты.
Однако, из за малограмотности авторитетов в SEO среде, получил распространения миф, о том, что SPA = Anuglar React или Vue. Что не так.
это фрейворки которые реализуют парадигму реактивного программирования, а НЕ инструменты для построения SPA приложений.
В результате, проблемы именно этих фреймворков, стали проецировать на SPA в целом. Которые, напомню, с 2012 года работают без каких бы то ни было проблем, как со стороны бразуеров, так и со стороны индексирующий роботов.
Вбейте себе в голову
SPA != Angular React или Vue.
Следующий миф пришедший ровно от туда же, а именно
Progressive Web Applications.
Это не стек технологий. Это вообще никакого отношения к технологиям не имеет. Это ярлык. Который получают тогда, когда на сайте используется ServiceWotker + написан Manifest.
ВСЕ.
Любой сайт, может работать со всем что дает ServiceWorker без ярлыка PWA.
Все что нужно для получения PWA в этом случае, это написать минимально корректны manifest.json который все что дает, это управление цветовой гаммой и сплеш скрином.
Ну и еще дает возможность подстраивать интерфейс бразуера.
И, как следствие, дает возможность продаваться через магазин. Что существует уже с пол года, а не анонсировано.
Нет ни единой технологии, которую бы сайт не мог использовать самостоятельно, без ярлыка PWA.
Займитесь собственным ликбезом, а не повторяйте безграмотные вещи от других SEO специалистов.repjov Автор
16.05.2019 23:45Типичный пример материала, который наглядно показывает почему SEO специалистов не любят — из-за тотальной технической беграмотности.
Почему вы решили, что эта статья от SEO специалиста или кого-то связанного с SEO?
Вбейте себе в голову
SPA != Angular React или Vue.
Где в статье написано, или вывод в том, что Angular или другой фреймверк это SPA?! Зато там написано:Single Page Application (SPA) – это веб-приложение, компоненты которого загружаются единожды на одной странице, а контент подгружается по необходимости.
Angualr, React и другие современные фреймверки просто помогают релизовывать такие страницы, конечно можно сделть это все на Vanila js используя XMLHttpRequest или jQuery. А проблема SEO, в другом, в том что используя клиентский роутинг фреймверков, страницы рендерятся на клиенте используя и строят DOM с данными уже после того как страница была отдана сервером, и при прямом переходе на ссылку клиентского роутинга, сервер всегд отдавал index файл, и уже после клиентское приложение сторило необходимую стрницу, и не все роботы умеют обрабатывать такие страницы.
Это не стек технологий. Это вообще никакого отношения к технологиям не имеет. Это ярлык. Который получают тогда, когда на сайте используется ServiceWotker + написан Manifest.
Тут можно холиварить до усрачки. Это все зависит какой смысл вложен в слово «технология». Ведь каждый ответит по своему. Мне близко это определение.
Технология — это совокупность знаний, посвященных созданию инструментов, обработке действий и извлечению материалов.
Ведь не всегда браузеры умели запускать server workers, не всегда умели работать с пушами, это все развивалось и продолжает развиваться. Можно PWA назвать и методологией, и подходом к разработке, да не важно как ты его назовешь, главное это релально классная штука, которая может улучшить веб-сайт. Которая, совмещает в себе многие классные вещи веба и мобильных приложений.
Займитесь собственным ликбезом, а не повторяйте безграмотные вещи от других SEO специалистов.
И поверьте, у меня достаточно опыта и знаний в веб-разработке, чтобы писать и говорить на такие темы. Я не занимаюсь копирайтингом или бездумно переписываю чужие статьи, я все это применял, и моя команда применяет это все и по сей день!
Kowi
17.05.2019 22:44PWA штука шикардецкая, внедрил у себя. на Serverless посматривал, однако сам исполнить не осилю, а работягу по карману пока не нашёл.
В принципе, тенденции здравые. Пажждём, что будет дальше.
tsepen
PWA очень крутая штука, Гугль уде анонсировал возможность размещения pwa в play market, если подтянется яблоко и реализует возможность размещения в app store, то мобильная разработка как самостоятельный вид деятельности вообще станет не актуальной. Пилишь сайт, в бонус получаешь мобильные апликухи :)
repjov Автор
Да, мне тоже очень нравится это направление.
Skycaptain
При условии, что вам не нужно ничего, кроме экрана и клавиатуры
Vadem
Не совсем так.
PWA имеют доступ к камере, микрофону, геолокации, USB, статусу батареи, положению устройства, платежам и многому другому. NFC и Bluetooth на подходе.
Нет доступа к SMS, контактам и некоторым другим фичам, но это явно больше чем только экран и клавиатура.