możesz mieć zespół samych TypeScriptowców i mogą pracować.
Tego nie rozumiem. Przecież nie możesz mieć całej logiki biznesowej we froncie. Gdzie tu bezpieczeństwo?
Czemu nie?
Masz bazę jako usługę. Do bazy dopisujesz serverless zasady bezpieczeństwa. Użytkownicy w bazie są tworzeni i mają swoje ID.
Po stronie frontu masz całą logikę np. pobierz z bazy wszystkie moje faktury i coś tam z nimi zrób.
W usłudze serverless piszesz prostą regułę - użytkownik A może mieć dostęp tylko do swoich faktur. Dla innych rzuć 401.
W locie po kluczach dostępowych jest zaimplementowana autoryzacja czy możesz się połączyć z bazą danych - masz to w ramach usługi.
Do zasad bezpieczeństwa możesz dopisywać nawet całe funkcje np. musi to być użytkownik, którego to są jego faktury oraz musi mieć zdefiniowany profil o typie READ_INVOICE.
Sama baza danych może być wykorzystana w klasycznym ujęciu tzn. piszesz sobie backend, który wystawia po REST / whatever, dostępy i modyfikacje danych - tylko po co ten element jak nie jest potrzebny?
Nie zawsze opłaca się dokładać nadmiarowej pracy jak to nic nie daje.
https://firebase.google.com/docs/firestore/security/get-started
// Allow read/write access on all documents to any user signed in to the application
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth.uid != null;
}
}
}
> service cloud.firestore {
> match /databases/{database}/documents {
> // True if the user is signed in or the requested data is 'public'
> function signedInOrPublic() {
> return request.auth.uid != null || resource.data.visibility == 'public';
> }
>
> match /cities/{city} {
> allow read, write: if signedInOrPublic();
> }
>
> match /users/{user} {
> allow read, write: if signedInOrPublic();
> }
> }
> }
