Створення інструменту управління проєктами за допомогою Prisma
Я створюю інструмент для спільної роботи над проєктами, подібний до Trello. Я використовую React, Express.js, PostgreSQL та Socket.io.
Перший крок — це схема бази даних. Я розробив шість моделей для роботи з користувачами, проєктами, дошками, завданнями, коментарями та сповіщеннями.
Ось основні технічні рішення та висновки з мого проєктування схеми Prisma:
• Використання CUID для ID
Я використовую @default(cuid()) для всіх ID. Вони кращі за звичайні числа для публічних URL-адрес. Це заважає людям вгадати, скільки записів у вас є.
• Явні назви зв'язків
Коли два поля вказують на одну й ту саму модель, Prisma може виникнути плутанина. Наприклад, завдання має автора (creator) та виконавця (assignee). Обидва є користувачами (Users). Я мушу явно називати ці зв'язки за допомогою імен @relation, щоб уникнути помилок міграції.
• Проміжні таблиці для зв'язків «багато до багатьох»
Користувач може належати до багатьох проєктів. Проєкт може мати багато користувачів. Я створив модель ProjectMember, щоб пов'язати їх. Я додав унікальне обмеження для userId та projectId. Це запобігає повторному приєднанню того самого користувача до одного проєкту.
• Ієрархія та логіка
Завдання не знаходяться в проєктах. Вони знаходяться на дошках. Дошки знаходяться в проєктах. Це спрощує функцію drag-and-drop. Щоб перемістити завдання, потрібно лише оновити його boardId.
• Nullable-зв'язки
Деякі зв'язки є обов'язковими, а деякі — необов'язковими. Завдання обов'язково має мати автора, тому я не використовую знак питання. Виконавець є необов'язковим, тому я використовую User? та String?. Ви повинні вказати обидва, щоб схема працювала.
Поширені помилки, які я знайшов:
- Використання одинарних лапок для значень за замовчуванням. Prisma вимагає подвійних лапок.
- Забування двокрапки в синтаксисі посилань (references syntax).
- Випадкове застосування
@default(now())до поля ID.
Далі я створю бекенд на Express та налаштую Socket.io для оновлень у реальному часі.