Выбор BaaS или CMS

JSON файлы товаров

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

Проще перейти уже к нормальному бэкенду, с динамичными данными.

Выбор CMS

После довольно долгого исследования рынка для реализации витрины и, частично, магазина, выбор пал на Supabase.

Основными критериями при выборе на этом этапе были:

• Простота
• Open source
• Бесплатность при использовании из облачных сервисов (это нужно не только нам, но и тем, кто будет использовать наш проект)
• RDBMS (SQL) в качестве базы данных (почему не подошел Firebase)
• Возможность потом несложно переехать на другой сервис/БД/свой сервер.

Большинство CMS продуктов предлагает платные low-code решения, завязанные на них и оперирующие не с данными, как нам надо, а с более высокоуровневыми конструкциями для построения сайта.

Среди Baas (Backend as a Service) решений были рассмотрены Firebase, Appwrite, Supabase, Amplify.

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

Сервисы Supabase

Supabase предлагает непосредственно Postgres базу данных (можно подсоединяться прямо к ней), API сервис для доступа к базе данных посредством REST запросов, сервис для парольной и OAuth аутентификаций, Edge Functions (серверные функции), на которых можно реализовать логику бэкенда. Лимиты бесплатного плана достаточно большие.

В дальнейшем возможно разворачивание Postgres на своем сервере и использование Supabase кода через Docker, либо своего API слоя. При желании можно будет даже поменять базу на MySQL. Всё это очень важная гибкость выстраиваемой архитектуры. Если мы чего-то не учтем сейчас, или ошибемся, то потом можно будет внести изменения с некритичными затратами.

Адаптеры

Мы помним, что одним из факторов успеха при создании сложной системы является её разбиение на слабосвязные более простые подсистемы. Конкретно тут мы имеем подсистемы "База данных", "Бэкенд (API сервис Supabase)", наш фронтенд.

Компоненты фронтенда должны обмениваться данными с API Supabase. Если мы в каждом компоненте будем прописывать обращение к API через Fetch или Axios, то при замене Supabase на другой бэкенд, или на наш свой, по всему коду фронтенда надо будет делать изменения, что очень затратно. Для нивелирования этого вызовы к API выносятся в отдельный модуль - api, и теперь в компонентах будет только вызов api.products(), который при смене бэкенда менять не надо, нужно будет поменять только его реализацию в api.

В этом случае, мы применяем шаблон проектирования "Адаптер". При работе, например, с Firebase нам нужно будет написать другой адаптер, при работе со своим бэкендом - еще один. Каждый из них будет преобразовывать запрос к определенному эндпойнту за списком товаров в массив для возвращения в функции api.products().

Когда делают системы широкого пользования, то предусматривают подключение к различным сервисам. Например, тот же Vue Storefront имеет адаптеры для интеграции с API бэкендов Magento, PrestaShop, Spree и других ecommerce решений.

Но у нас пока только Supabase, концентрируемся на нём.