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

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

Но, сперва небольшая предыстория. Много лет назад мы разрабатывали сайты на Битриксе. В один момент мы поняли, что с нашими нестандартными задачами разработка костылей к Битриксу занимаешь больше времени, чем разработка на фреймворках с нуля. А еще сайты на фрейворках работают быстрее, багов меньше, а писать код под нормальную архитектуру – приятнее. Так мы перешли на работу с фреймворками.

Все было классно, кроме одного: админки. У дизайнеров обычно не хватало времени её продумать, разработку админки с нуля мы обычно не закладывали в бюджет и поэтому делали ее по остаточному принципу. Все время пытались найти что-то подходящие: использовали bootstrap, чтобы были готовые сетки и компоненты, ставили разные темы для админок, интегрировались с trello и CRM для управления сайтом, иногда даже брали какой-нибудь wordpress.com и прикручивали наш фронт к нему по API.

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

Пару лет назад начали активно развиваться headless cms. Это такие CMS которые не содержат шаблонов и просто отдают данные через API. Настраиваешь структуру данных, под нее автоматически создаются формы для редактирования. Есть облачные (Contentful, GraphCMS, Prismic), есть opensource (Strapi, Prisma). Часто их сайты выглядят круто и при первом подходе они выглядят как волшебная таблетка.

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

И вот сейчас можем сказать, что мы нашли что искали.
https://www.sanity.io/ – это микс облачной нереляционной базы данных с API (типа, как firebase) и опенсурсной Sanity Studio для редактирования контента. Расскажу тезисно:
– У нее есть полноценная бесплатная версия с ограничениями по количеству запросов и записей в базе данный. Но ограничения очень щедрые, их хватит для многих сайтов: https://www.sanity.io/pricing
– API предоставляет доступ по GraphQL и GROQ (это что-то ими придуманное, но неплохо сделано).
– В API встроены всякие штуки, типа CDN с возможность ресайза картинок. Это когда в админку ты загружаешь картинку 5000х5000 пикселей, а в нужный момент она отдаст тебе превью 120х80.
– Мультиязычность реализуется очень красиво: https://www.sanity.io/docs/localization
– Есть история изменений контента. Можно сохранять черновики и даже делать preview черновиков на своем сайте. Например, загрузили новую фотку для товара, посмотрели как выглядит на сайте и только потом опубликовали.
– Можно создавать поля типа array содержащие несколько разных типов данных внутри. Сложно объяснить, но это очень круто.
– С вложенными или связанными данными очень удобно работать и в админке и в API.
– Вы можете создавать свои типы данных любой сложности. Схема данных и структура админки описывается js-конфигами (возможно, разберется даже дизайнер). Удобно – можно переносить одинаковые сущности из проекта в проект.
– Sanity Studio написана на React, если чего-то не хватает, можно написать свои компоненты или использовать готовые. Посмотрите, какая штука есть для типа данных «видео»: https://www.sanity.io/blog/first-class-responsive-video-support-with-the-new-mux-plugin
– Редактор текста отдает текстовый контент в json, а не html. Это очень круто потому, что можно легко менять дизайн текстового контента без изменения данных.

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

Так выглядит Sanity Studio.

Ходили с Денисом на встречу, обсуждали наш наглый отказ заполнять тендерный бриф потенциального клиента )

Проект интересный, но блин, не вписывается наша работа в такие рамки. Мы не делаем формы, корзины, фильтры поиска.

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

Иногда, для этого нужны формы, корзины, фильтры. Иногда нет.

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

Интерфейсы, это как проявление природы современной компании, как лица, как органы чувств. Они сами по себе уже несут сообщение. «Мы делаем так» → «мы такие».

Это не всегда про деньги напрямую (больше конверсия!). Скорее, про идентичность, характер, будущее.

Поэтому вопрос в формате «с каким характеристиками вы сделаете нам корзину» нас немного расстраивает 🙂

Помните концепцию? Недавно запустили новую версию stomweb.ru, образовательного онлайн-сервиса для стоматологов (мы тоже не знали, что так бывает)

Недавно мы перезапускали stomweb.ru, за последние годы это один из самых проблемных запусков по количеству косяков. Расскажу о некоторых.

Косяк №1. Keep it simple stupid.

На днях клиент написал: опять сломался счетчик просмотра статей.

Стали разбираться: количество просмотров статьи не меняется если пользователь не авторизован и не может ее прочитать.

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

Но это даже не первая «проблема» со счетчиком просмотра на этом сайте. Изначально мы сделали систему, которая засчитывала только один просмотр от каждого пользователя: хранили каждый просмотр с user_id и не создавали повторный если просмотр от такого пользователя уже был засчитан. Логично же. Клиент настоял это убрать, потому что с его стороны тоже логично: больше цифры на счетчике прсмотров – лучше.

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

Что делать, чтобы не наступать на такие грабли?
1. Всегда стараться идти по более простому пути. Да, может оказаться, что нужно было реализовать сложнее, но хотя бы не будет впустую проделанной работы.
2. Если хочется усложнить и сделать лучше – нужно обсудить со стейкхолдерами.

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

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

На новом проекте решили попробовать фреймворк для e2e тестов – Cypress. Эта штука позволяет имитировать действия пользователя, прогонять основные сценарии в браузере и автоматически проверять все ли сработало верно. Нам очень понравились скорость, надежность и простота.
Видео тоже можно записывать.

–––

Леонид: А я только в понедельник на собеседовании говорил, что наше слабое место – тестирование. Спасибо Вове, что двигает нас вперед.

Пафосная заставка, после которой разговор про Breadhead, разработку, путь от сайтов за 15 000₽ до 5 000 000₽, жизнь, политику и даже про медитацию. Полтора часа! (из которых час сижу в 🕶 от PYE: во-первых они очень крутые, ношу их с собой даже зимой, во-вторых, как говорит Сергей Мезенцев, это альфа-поведение, а на самом деле чтобы меньше показывать стеснение)

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

Спасибо Коле из Loftblog за приглашение.

https://www.youtube.com/watch?v=C5z7ouFrLN8