Беги подальше от reg.ru. Часть 2

Итак, сайт заказчика превысил допустимый порог размера базы данных. «Расширенная» техподдержка рекомендует «перенести сайт на CloudVPS, там нет ограничений на размер базы данных». Окей, то есть сайтовый хостинг возможностей расширения не имеет.

Что делает заказчик в этом случае (напоминаю, что бизнес теряет деньги каждую минуту простоя сайта)? Конечно, бежит подключать этот CloudVPS. Знаешь, сколько вариантов тарифов для этой услуги? 29, Карл! Они ещё на группы делятся: стандартные, высокочастотные и выделенные. Как рядовой пользователь хостинга (например, владелец интернет-магазина) должен разобраться в том, с какой частотой процессор нужен для того, чтобы поднять его сайт…

Разумеется, заказчик выбирает первый попавшийся, ориентируясь по стоимости. И бежит обратно в поддержку, чтобы узнать, когда сайт станет доступен. Бравые поддерживальщики отвечают гениальное: «Как вижу вы приобрели Облачный сервер. Чтобы сайт стал доступен необходимо перенести его на этот сервер. Если вам необходима наша помощь, то вам необходимо приобрести сервер с панель управления, например ISPManager … поскольку наши специалисты осуществляют перенос только на серверы с панелью управления.»

Эмм, то есть вы попросили купить CloudVPS, при этом не объяснив даже, что именно выбрать, а после того, как заказчик приобрёл сервер, выясняется, что это не то, что надо было. А что так можно вести себя с клиентами? Почему технические специалисты хостинга не способны сами установить ISPManager (панель управления) на чистый сервер, для меня остаётся загадкой.

В этот момент уже подключаюсь я, приобретаю нужный сервер с предустановленной панелью и пишу запрос на перенос сайта. Сам пытаюсь войти в панель управления сервера, получаю ошибку загрузки страницы и отправляю им скриншот того, что не могу достучаться до админки. Горячо любимые ребята отвечают: «Панель управления открывается корректно», и присылают скриншот. IT-классика, ага: у меня всё работает.

Думаешь, это всё? Как бы не так, продолжение следует)

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

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

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

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

Одним из таких инструментов является Amplitude – комплексный инструмент для сбора данных и построения аналитических панелей (дашбордов). На нём можно довольно быстро собрать себе панель управления по вкусу и нуждам. К тому же он бесплатный, пока ты не нагрузишь его больше, чем 50 000 событий в течение месяца, так что для начала, думаю, хватит.

С точки зрения сложности внедрения эта штука одна из самых простых на рынке, работает не сложнее чем известные всем Яндекс.Метрика или бывшая Google Analytics. Правда, покодить всё же придётся.

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

На этой консультации я выяснил, что само приложение сейчас реализовано на Bubble, а бэкенд разработан самостоятельно, то есть это не no-code. Проблема заключалась в том, что вся эта связка работает очень медленно и приложение неюзабельно с точки зрения пользователя. И задача команда разработки заключалась в том, чтобы перейти на новый фронт с Бабла.

Но самое ли это оптимальное решение в данной ситуации? И что меня больше всего насторожило – это то, что Bubble сейчас лидирует на рынке no-code и вряд ли им бы пользовалось такое количество людей, было собрано огромное комьюнити, они привлекли бы столько денег на развитие, если бы приложения, собранные на этой платформе, были не юзабелены.

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

Будем разбираться, в чём же тут дело, и как можно решить эту задачу.

Стартап-проект, связка Bubble + самописный бэкенд. Проблема – сайт работает очень медленно, пользоваться невозможно.

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

Начнём с бэкенда – того, что скрыто под капотом. Программная часть, которая обрабатывает данные, работает с базой, в общем делает всё, что скрыто от глаз пользователя. В общей связке программного комплекса – это двигатель, от скорости работы которого в принципе зависит возможная потенциальная скорость всей машины.

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

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

В данном случае мы видим, что данные по запросу возвращаются очень быстро, за доли секунды, как в принципе и должно быть. Отправили запрос – сервис ответил, скажем, за 0,25 секунды. Но на фронте данные появляются значительно позже, только секунд через 15-20.

Копаем дальше.

Что может тормозить web-приложение

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

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

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

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

Конструкторы вроде Tilda – это как поход в Макдак (и точка), где ты выбираешь из готовых блюд и на выходе получаешь ожидаемого качества обед. А Bubble – это магазин с ингредиентами, из которых тебе самому всё надо приготовить. Получится ли из этого шедевр или что-то, что придётся отдать коту, зависит полностью от тебя. Котяра, кстати, вероятно тоже не станет это употреблять.

Поэтому грамотно и чисто собранный Bubble – это важная составляющая быстрого приложения. Но это ещё не всё, остался ключевой элемент паззла.

Как ещё можно оптимизировать скорость работы web-приложения

Ещё одна точка преткновения, которую я обнаружил, консультируя заказчика – это объём передаваемых данных. Да, бэкенд работает молниеносно, API отвечает за доли секунды. Но порция данных, которую сервис вываливает на фронт – тысячи позиций за раз. А теперь приложению в браузере нужно как-то это всё прожевать, переварить и выдать полезные вещества из этих данных на экран.

А теперь и самому пользователю надо проделать всё то же самое: как-то воспринять этот объём информации и выудить оттуда нужное. Ведь у него и так мало инфы в течение дня: подумаешь, пара сотен постов в Инсте, с десяток умных каналов в Телеге (ага) и несколько видосов на Ютубе, просмотренных залпом.

Представь грузчика, который разгружает кузов, набитый небольшими коробками. если это самосвал, то можно опрокинуть его прямо на грузчика и уехать. Вот таким самосвалом сейчас API отгружает данные на фронт. Конечно, рано или поздно он всё разгребёт, но не будет ли более эффективным разбить данные на порции и подавать нашему работнику их партиями по 5 коробок за раз?

А теперь со стороны пользователя. Представь, что ты приходишь в аптеку и примерно знаешь, что тебе нужно приобрести. Говоришь это в окошке, а тебе приносят пару коробок, в которых свалены сотни разных лекарств, где точно есть искомое. Примерно так выглядят данные без фильтров на фронте.

Но ведь в жизни работает намного эффективнее, чем в некоторых приложениях! Ты подходишь к фармацевту, и он приносит тебе на твой запрос 2–4 варианта, из которых намного легче выбрать, задав ещё пару уточняющих вопросов. Это и есть фильтрация данных на фронте.

Итак, первое – фильтрация данных на входе. Разбей их на порции, добавь пагинацию (переключение страниц или подгрузка при скролле). Прикрути дополнительные фильтры, которые помогут вычленить нужное и ограничить выборку ещё больше. Тем самым облегчишь жизнь и бэку, и фронту, и пользователю.

Соберу воедино всё, на что стоит обратить внимание в первую очередь при анализе скорости работы web-проекта по мотивам консультации заказчика

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

2. Для этого последовательно проверяем все составные элементы архитектуры. Разумеется, предварительно надо описать архитектуру хотя бы на верхнем уровне для понимания, с чем мы работаем.

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

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

5. Интеграционный слой – связь между бэком и фронтом. Насколько грамотно она организована, как далеко серверы расположены друг от друга, нет ли ограничений с обеих сторон (со стороны передачи или приёма)?

6. Оптимизация передачи данных. Разбить на порции, применить фильтры, ограничить поток.

И последнее. Переходить на новую платформу (как фронт, так и бэк) – всегда очень болезненный, долгий и ресурсоёмкий процесс. Если переводить в деньги, то сильно дешевле будет оптимизировать текущую конструкцию, чем строить новую.

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

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

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

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

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

А пока…

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

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

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

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

А пока пусть всё идёт своим чередом, ничего не меняется и продолжается прежний ежедневный цикл.

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

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

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

Всё это читать больно, неприятно. Однако ты понимаешь, что доля правды в этом есть.

И я это знаю как никто другой, потому что ощущал именно то же самое. Долгое время.

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

Жить в ритме: дом, работа, нелюбимые задачи, которые не вызывают ничего, кроме отвращения, но при этом зажмурившись от необходимости, потому что это приносит деньги, продолжать это делать. Семья. Классический отдых по пятницам. Бухло. Иногда покупки чего-то нового. Для дома, для себя, для семьи.
Несколько раз в жизни большие покупки вроде машины, дома, квартиры. И раз в год, а некоторым счастливчикам, кому повезло, несколько раз в год, отпуск, на который копишь весь оставшийся год и повторять этот цикл до пенсии.