Made on
Tilda
Интеграция с внешним backend и базой данных: форма → webhook → прослойка → БД
Программа
| Занятие | Дата и время | Модуль | Части | Итог занятия |
|---|---|---|---|---|
| 1 | 23.10.26 16:20–17:50 | Архитектура MVP и проектирование данных | 1. Tilda как frontend-слой 2. Данные и сценарий | Схема MVP и ER-модель |
| 2 | 23.10.26 18:00–19:30 | Сборка frontend-интерфейса в Tilda | 3. Страницы, блоки, формы 4. Форма к передаче данных | Опубликованная страница с формой |
| 3 | 30.10.26 16:20–17:50 | Интеграция Tilda с backend и БД | 5. Webhook 6. Запись во внешнюю БД | Заявка из Tilda в таблице Supabase |
Каждое занятие — две части по 45 минут. Модуль 1 ведут Оля и Витас, модули 2–3 — Витас.
Сквозной кейс
01
выбирает услугу и дату
02
страница и форма
03
POST с данными формы
04
ключ, проверка, дубли
05
клиенты и заявки
Tilda показывает, прослойка решает, БД хранит.
01
Модуль 1 · Занятие 1
Какую роль Tilda может выполнять в архитектуре цифрового продукта
Слои продукта
Зал и официант.
Страницы, формы, кнопки — всё, что видит пользователь.
Кухня.
Проверяет данные и применяет бизнес-правила.
Склад и журнал заказов.
Таблицы, где живут записи.
Кухня на аутсорсе.
Готовые БД, права и функции без своего сервера.
Как слои общаются
Договорённость: куда, в каком виде и что отправлять, что вернётся в ответ.
Текстовый формат данных:
{"name": "Анна"}
Сервис сам отправляет POST на ваш URL, когда происходит событие — например, отправлена форма.
Tilda: сильные стороны и границы
Демонстрация · редактор Tilda
01
Страницы и блоки. Экран собирается из готовых блоков, порядок меняется перетаскиванием.
02
Zero Block. Свободный холст, когда готового блока не хватает.
03
Форма. Поля, обязательность, проверка email — всё настройками, без кода.
04
Каталог. Товары и услуги живут внутри Tilda как данные, но только для витрины.
05
Блок T123. Свой HTML и JavaScript прямо на странице.
06
Публикация. Страница уходит в интернет — и всё на ней становится общедоступным.
Пункты 1–5 — это весь frontend-слой. Пункт 6 — причина, по которой нужен слой за пределами Tilda.
Типовая архитектура
заполняет форму
→
клиентская проверка
→
webhook / serverless
→
хранение
→
сообщение, уведомление
Frontend никогда не ходит в БД напрямую.
REST API на базовом уровне
POST /functions/v1/tilda-webhook HTTP/1.1 ← метод и адрес Host: abc.supabase.co Content-Type: application/json ← заголовки {"name": "Анна", "email": "anna@example.com"} ← тело
Методы
GET получить · POST отправить · PATCH изменить · DELETE удалить
Коды ответа
2xx успех · 4xx ошибка клиента · 5xx ошибка сервера
Демонстрация · Ctrl+U
Ключ в T123, в скрытом поле или в минифицированном JS — это публичный ключ. Проверки в браузере обходятся прямым POST-запросом через curl.
Риски прямого подключения
| Что осталось на странице | Что сделает посторонний | Как правильно |
|---|---|---|
| Ключ доступа к базе | Открывает таблицу и читает все заявки: имена, телефоны, email клиентов | Таблицы закрыты, обращается к ним только прослойка |
| Право записи с клиента | Шлёт запросы мимо формы и заливает тысячи мусорных строк | Пишет только прослойка — с проверкой и защитой от дублей |
| Сервисный ключ | Получает полный доступ: правит чужие статусы, удаляет таблицы целиком | Сервисный ключ лежит в секретах функции, на страницу не попадает |
| Проверки только в форме | Отправляет POST напрямую и обходит всю валидацию разом | Прослойка проверяет данные заново, не доверяя источнику |
Проверка на стороне клиента — удобство для пользователя, а не защита.
Мини-артефакт урока 1
Вопросы для самопроверки
01
Какие три слоя есть в архитектуре и за что отвечает каждый?
02
Чем webhook отличается от обычного API-запроса?
03
Назовите два ограничения Tilda, из-за которых нужен внешний backend.