Payload CMS - Co będziemy budować (cz. 2)
Zainspirujmy się dostępnymi na rynku rozwiązaniami i zdefiniujmy co będziemy budować w tej serii.
Artykuł należy do serii Payload CMS - marketplace z projektami Payload.
Intro
Marketplace z projektami PayloadCMS to nielada wyzwanie. Wymaga przemyślanej strategii działania, jasno zdefiniowanych celów i zaplanowanych kroków. W tej części serii Payload CMS - marketplace z projektami Payload.: nadamy nazwę aplikacji, założymy repozytorium kodu, omówimy założenia i feature'y aplikacji oraz przejrzymy inspiracje.
Nazwa aplikacji
Korzystając z pomocy LLM otrzymałem kilka potencjalnych nazw aplikacji. Oto one:
- PayloadHub
- PayloadForge
- PayloadStack
- PayloadBase
- PayloadCloud
- PayloadMarket
- PayloadWorks
- PayloadKit
- PayloadFlow
- PayloadLaunch
Finał losowania
Bęben maszyny losującej wylosował liczbę 6, więc wybrałem nazwę PayloadMarket.
Repozytorium projektu na portalu github
Aby dzielić się postępami w pracy stworzyłem repozytorium na github-ie.
Oto link do repozytorium PayloadMarket
Założenia aplikacji PayloadMarket
Multi Tenancy
Głownym założeniem aplikacji PayloadMarket jest Multi tenancy w modelu shared database.
To oznacza, że aplikacja będzie podzielona na organizacje / dzierżawców (tenants). Wszystko odbywać się będzie w obrębie jednej bazy danych.
Każdy użytkownik:
- Loguje się do tego samego PayloadMarket'a jednak do innej organizacji (jak workspace w aplikacji Slack)
- Nie widzi danych innych firm
Każda organizacja / dzierżawca:
- Ma własne rekordy w bazie danych
- Posiada własnych userów podzielonych na role.
Podział userów
- Z dostępem do panelu administracyjnego (główny administrator aplikacji)
- Z dostępem do panelu organizacji
- Z dostępem do aplikacji końcowej (klient chcący kupić aplikację PayloadCMS)
Inspiracje
Feature'y
Lista feature'ów, które przedstawię w aplikacji PayloadMarket.
- Zakładanie konta oraz logowanie do panelu organizacji
- Zatwierdzanie organizacji z poziomu panelu administracyjnego
- Zarządzanie organizacją (dodawanie i usuwanie użytkowników, nadawanie i zmiana ról)
- Tworzenie assetu przez organizację
- changelog danego assetu
- Kategoryzowanie assetu
- Search w aplikacji użytkownika końcowego
- Filtrowanie w aplikacji użytkownika końcowego
- Ze względu na czasochłonność skupimy się tylko i wyłącznie na widokach w rozdzielczości Desktop
Dodatek
Jako dodatek zaimplementujemy moduł do trackowania ticketów / issues związanych z danym rozwiązaniem. Dobrym przykładem tego rozwiązania są github issues.
Issues będą wyświetlane użytkownikowi organizacji w postaci tablicy kanban. Statusy danego ticketu będą następujące:
- Zgłoszony
- Odczytany
- W trakcie rozwiązywania
- Rozwiązany
Outro
Danym artykułem przybliżyłem wizję tworzonej aplikacji. Nie ukrywam, że dalszy przebieg tej serii, w dużej mierze może być impowizacją.
Niemniej jeśli interesuje Cię temat Payload CMS bądź szukasz rozwiązania aplikacji z wbudowanym systemem autoryzacji i znasz Next.js zapraszam do dalszej podróży :).
Z developerskim pozdrowieniem! HOWGH!
Data ostataniej edycji