Як додати базу даних до застосунку (без втрати даних згодом)

Щоб додати базу даних до застосунку, оберіть керовану реляційну базу даних (зазвичай за замовчуванням обирають Postgres), зберігайте рядок підключення в секреті на сервері, створіть одну таблицю для кожного типу об'єктів, які зберігає застосунок, і нехай ваш бекенд — а не браузер — читає та записує в неї дані. Якщо ви створюєте застосунок за допомогою конструктора на базі ШІ, зазвичай достатньо сказати «збережи це в базу даних», і агент налаштує таблиці та код. Ваше завдання — чітко описати дані та перевірити, що вони справді зберігаються.

Цей посібник пояснює, коли потрібна база даних, які є основні варіанти, як описати свої дані та які помилки призводять до втрати або витоку даних.

Коли застосунку потрібна база даних

База даних потрібна, коли ваш застосунок має запам'ятовувати щось після закриття сторінки або ділити дані між людьми. Типові ознаки:

• Відвідувачі надсилають щось: форму, реєстрацію, бронювання, замовлення
• Користувачі мають облікові записи зі своїм збереженим вмістом
• Адміністратор має бачити або редагувати те, що створили інші
• Вам потрібні звіти або підрахунки за період

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

Ваші варіанти

Для більшості невеликих і середніх веб-застосунків правильний вибір за замовчуванням — реляційна база даних на кшталт Postgres. Вона добре працює зі зв'язками (один клієнт має багато замовлень), забезпечує узгодженість даних і дозволяє пізніше відповідати на питання за допомогою SQL. Огляд Postgres простою мовою дивіться в що таке Postgres.

Опишіть свої дані до створення

Найкорисніше, що можна зробити, — записати об'єкти, які зберігає ваш застосунок, і як вони пов'язані. Знати жаргон баз даних не потрібно. Для застосунку бронювання це може бути таким:

• Клієнти: ім'я, електронна пошта, телефон
• Послуги: назва, тривалість, ціна
• Бронювання: який клієнт, яка послуга, час початку, статус (очікує, підтверджено, скасовано)

Це три таблиці. «Який клієнт» і «яка послуга» стають посиланнями (зовнішніми ключами) між ними. Правильно все визначити на початку важливіше, ніж будь-який технологічний вибір, адже змінити структуру даних, у яких уже є реальні рядки, складніше, ніж змінити макет сторінки.

Кілька практичних правил:

• Одна таблиця для одного типу об'єктів. Не запихайте замовлення в текстовий стовпець у таблиці клієнтів.
• Кожен рядок має ідентифікатор і час створення. Вони знадобляться пізніше.
• Використовуйте правильні типи. Дати — як дати, гроші — як цілі центи або десяткове число, а не як текст.
• Позначайте обов'язкові поля як обов'язкові. Нехай база даних відхиляє некоректні дані, а не лише форма.

Приклади промптів

Почніть з однієї функції, а не з усієї схеми відразу:

Додай базу даних до цього застосунку. Створи таблицю bookings з ім'ям клієнта, електронною поштою, послугою, часом початку та статусом (очікує, підтверджено, скасовано; за замовчуванням очікує). Зберігай надсилання з форми бронювання в цю таблицю, показуй повідомлення про успіх і додай сторінку адміністратора, яка виводить бронювання від найновіших.

Потім розширте:

Додай таблицю services (назва, тривалість у хвилинах, ціна в центах). Замість текстового поля послуги в бронюваннях зроби посилання на services і перенеси існуючі бронювання, не видаляючи їх.

І посильте:

Переконайся, що всі читання та записи в базу даних відбуваються на сервері. Браузер ніколи не повинен отримувати рядок підключення до бази даних. Перевіряй електронну пошту та час початку на сервері перед вставкою.

Крок за кроком

1. Складіть список даних за описом вище: об'єкти, поля, зв'язки між ними.
2. Створіть базу даних. В конструкторі на базі ШІ попросіть про це в чаті. В інших місцях створіть керовану інстанцію Postgres і скопіюйте її рядок підключення.
3. Збережіть рядок підключення як секрет (змінну середовища на сервері), ніколи в коді. Див. змінні середовища та секрети.
4. Створіть таблиці. Використовуйте міграції — версіоновані скрипти, що змінюють схему, — щоб зміни були повторюваними та оборотними.
5. Побудуйте серверні маршрути, які створюють, читають, оновлюють і видаляють рядки (CRUD). Браузер викликає ці маршрути; він ніколи не звертається до бази даних напряму.
6. Підключіть інтерфейс до цих маршрутів: форми, що зберігають дані, списки, що завантажуються, порожні стани, коли ще нічого немає.
7. Перевірте збереження. Надішліть щось, перезавантажте сторінку, відкрийте в іншому браузері. Якщо даних немає, значить, їх не було збережено в базу даних.
8. Перевірте доступ. Увійдіть як другий користувач і переконайтеся, що ви не бачите й не редагуєте дані першого.
9. Опублікуйте, потім перевірте знову на живій адресі, адже опублікований застосунок може використовувати інше підключення, ніж ваш попередній перегляд.

Типові помилки

• Зберігати в браузері й вважати, що це збережено. localStorage здається робочим, поки хтось не відкриє застосунок на іншому пристрої. Завжди тестуйте в другому браузері.
• Розміщувати рядок підключення у фронтенд-коді. Будь-хто може прочитати фронтенд-код. Це дає йому доступ до всієї вашої бази даних.
• Відсутні перевірки доступу. «Покажи мої замовлення» має фільтрувати за користувачем, який увійшов, на сервері, а не в інтерфейсі. Це найпоширеніша діра в безпеці застосунків, створених за допомогою ШІ; наш контрольний список безпеки розглядає це докладно.
• Деструктивні зміни схеми. Прохання «перейменуй таблицю» або «змін структуру» може видалити її та створити знову. Коли є реальні дані, скажіть: «перенеси наявні рядки, нічого не видаляй».
• Зберігати файли в базі даних. Зображення та PDF-файли належать до файлового сховища, а в таблиці зберігається лише їхня адреса або ключ. Див. як додати завантаження файлів.
• Немає резервних копій. Знайте, як ваша платформа створює резервні копії та як їх відновити, ще до появи клієнтів.

Контрольний список

• Кожен тип об'єктів має власну таблицю з ідентифікатором і часом створення
• Обов'язкові поля та типи забезпечуються базою даних
• Рядок підключення зберігається лише в серверних секретах
• Усі читання та записи проходять через серверні маршрути
• Кожен користувач може читати та змінювати лише свої рядки
• Дані переживають перезавантаження й відображаються в іншому браузері
• Зміни схеми виконуються через міграції та зберігають наявні рядки
• Ви знаєте, як працюють резервні копії та відновлення
• Живий застосунок перевірено після публікації

Додавання бази даних у Mythex

У Mythex кожен проєкт може отримати власну виділену базу даних Postgres як на Free, так і на Pro. Зазвичай не потрібно натискати окрему кнопку «підключити»: попросіть у чаті («зберігай адреси електронної пошти для списку очікування в базу даних») або введіть /database, і параметри підключення буде додано в робочий простір та ваш опублікований застосунок. У налаштуваннях проєкту видно, чи активна база даних.

База даних засинає після 5 хвилин бездіяльності й прокидається при наступному запиті. Використання в опублікованому застосунку тарифікується за час, протягом якого база фактично працювала, з того самого балансу кредитів, який ви використовуєте для створення. Якщо ви додали базу даних після публікації, опублікуйте застосунок знову, щоб живий застосунок її підхопив.

Див. Database та рецепт Build a CRUD app у документації. Щодо входу для даних окремих користувачів читайте як додати вхід до застосунку.

Запитання