It is wise to write a client application with current browser capabilities. I personally created a sophisticated application that uses only Firebase on the back, and HTML / JavaScript with CDN as a client. This is especially suitable for application types that have inherently simple security models:
- single-user applications (where data belongs and is changed by one person)
- chats and communication widgets
- applications that are closed to the organization, where client connections are authenticated and trusted, at least to a lesser extent (shared editors and CRM).
In some cases this is possible, but less suitable for tools with heavy computing, where even low-level user data must be carefully controlled by a trusted third party (for example, games in which players can crack their own statistics and calculate valid statistics require complex algorithms)
You can also significantly reduce server administration and configuration by replacing traditional APIs and server scripts with βprivileged consumersβ. They are also Firebase listeners with higher access privileges, who listen and process data in the same way as a client, and then write to protected data than ordinary users should not access or manipulate it.
The disadvantage of client models is the increased complexity of security. Each client needs to be trusted in order to calculate and store its own data or that the data must be carefully protected with the help of security rules or some kind of external monitoring (for example, a privileged consumer).
You can find interesting design ideas by going into the literature on the "Fat client" or "Fat client" design templates. You can also see distributed games for some ideas.
Kato
source share