Роботу над каталогом техніки ми почали з огляду готових інструментів. Нам був потрібен статичний сайт з можливістю редагувати контент у вихідних файлах. Ми обирали серед рішень, де робота з шаблонами побудована на React. Дуже швидко список кандидатів обмежився двома: Gatsby.js та Next.js. Після поверхневого знайомства з обома, Gatsby виглядав як ідеальне рішення – все мало пройти швидко та просто (спойлер – ні, все пішло не так). 

Коротко про Gatsby. Це генератор статичних сайтів з декількома ключовими особливостями. 

1. Він може брати контент для побудови сайту з різних джерел: структуровані файли різних форматів (YAML, JSON, etc.), документи у форматі Markdown та картинки,  REST API, CMS. 
2. З усіх джерел дані стікається в єдине деревоподібне сховище. Доступ до цього сховища надається через GraphQL. Потім для кожного типу сторінки ми в GraphQL запиті пишемо, які саме дані для неї потрібні.  
3. Для розширення своїх можливостей Gatsby пропонує каталог плагінів. 

Власне, наявність цих плагінів для важливих для нас задач здавалася вагомим аргументом за Gatsby. Так за допомогою плагінів ми планували вирішити задачу роботи офлайн та пошуку за назвою техніки. Але, не так сталося, як гадалося … 

GraphQL інтернам давався не просто. Знадобився деякий час розібратися, як отримувати потрібні дані та пов’язати, наприклад, сторінку с деталями про одиницю техніки та фотографіями для слайдеру. Зрештою зробили це мігрувавши з File System Route API на createPage API. До того на кожну сторінку про одиницю техніки ми генерували зайвих 100KB даних про картинки. 

Офлайн плагін не дозволив нам заздалегідь зберегти дані для всіх сторінок. Довелось його патчити під наші потреби. Плагін для пошуку не працював з українською мовою. Його теж патчили. Загалом, високий рівень абстракції та складний цикл побудови сайту, внесений Gatsby для підтримки тих самих плагінів, проводив до того, що ми більше часу розбирається, як вирішити якусь просту задачу ніж зайняло б саме її вирішення без нього. 

Окремий біль – це намагання створити PWA, який буде працювати офлайн. Через великий розмір початкових зображень та стандартні налаштування генерації адаптивних картинок, вихідний розмір всіх файлів становив близько 300MB. Скоротили до 10МБ. Потім перечитували код Workbox, ліби для та роботи офлайн через Service Worker. Нам потрібно було знайти шлях показувати прогрес прекешування ресурсів для роботи офлайн. Поточна проблема зараз – це CodeSpliting, через який декілька маленьких блоків коду не потрапляють в прекеш. В результаті, якщо користувач не відкриває певний тип сторінки, поки інтернет в нього є, то офлайн вона працювати не буде. CodeSpliting плануємо відключити, коли розберемося як. 

Тим не менш, розробка каталогу завершуєтсья. Фіксимо візуальні дефекти, доповнюємо контентом та готуємо до публікації в App Store. Все буде Україна! 

Хто зацікавився, зі структурою так кодом нашого каталогу ви можете ознайогомитись в репозиторії  https://github.com/softwareplanet/mec.