Aplikacje internetowe

W internecie znajduje się wystarczająco zasobów do nauki oraz instrukcji jak wykonać poszczególne elementy aplikacji internetowej, których nie zamierzam przepisywać na mojej stronie, jedyne potencjalne podejście, jakie widzę to napisanie możliwie krótkich wersów o tym, z czym miałem styczność do tej pory, aby udokumentować swoje doświadczenie.

Implementacja AuthN (Authentication) with JWT (JSON Web Token), OAuth 2.0, Passwordless (Email, SMS) and Basic (Username & Password) strategies wraz z AuthZ (Authorization) dla zarządzania dostępem do zasobów (RBAC, ACL).
Zarządzanie kontem użytkownika wraz z zapisywaniem danych osobowych w bazie danych oraz podstawowymi funkcjami zarządzania kontem użytkownika jak: zmiana nazwy użytkownika, zmiana adresu email, zmiana hasła, przywracanie hasła (jeśli konto posiada potwierdzony adres email), dezaktywacja konta, permamentne usuwanie konta. Przetrzymywanie informacji o kontach powinno być zgodne z OWASP.
Zarządzanie profilami do reprezentacji użytkownika poza bądź w ramach aplikacji, a jednocześnie nie są powiązane z kontami używanymi do autoryzacji oraz uwierzytelniania, takowe powinny być otwarte na możliwość integracji z zewnętrznymi serwisami w ramach potrzeby (np. CRM/ERP).
Modelowanie danych według indywidualnych modeli biznesowych wraz z kolaboracją z schema.org dla zachowania struktury, której zrozumienie nie wymaga wysiłku kognitywnego.
Logowanie oraz telemetria do zbierania informacji o realnych wydarzeniach w domenie aplikacji wraz z informacjami do debugowania na odpowiednich poziomach niżeli “płaskiego” logowania bez hierarchii.
Konfiguracja aplikacji w sposób schodkowy, przy użyciu parametrów z pliku wsadowego, plików konfiguracyjnych, zmiennych środowiskowych, przetrzymywania sekretów oraz interfejsu API. Udokumentowana i zachowująca takie same nazwy kluczy, z ewentualną różnicą w sposobie traktowania białych znaków. Ustalając domyślne ustawienia, które pozwalają uruchomić aplikację po wyjęciu z pudełka.
Implementacja wewnętrznego systemu płatności niezależnego od dostawcy (Stripe, płatność gotówką) w ramach aplikacji internetowej, rozróżniając różnice pomiędzy dostawcami, reprezentacją metody płatniczej dostępnej dla danego użytkownika oraz historycznego zapisu płatności aktywnie aktualizowanego poprzez nasłuchiwanie na wydarzenia w czasie rzeczywistym.

Napisałem tę notatkę, aby zwrócić uwagę na powtarzalność komponentów (według ich odpowiedzialności oraz spójności) przy aplikacjach internetowych. Zwracajmy uwagę na standaryzację oraz separację odpowiedzialności za komponenty w otwartym ekosystemie, oraz środowisku.

Sądzę, że egzystencja stablinie utrzymywanej i audytowanej biblioteki jest czymś, na czym można polegać bardziej niż indywidualnej implementacji gdzie ryzyko niedociągnięć jest dużo większe.