I've described the following separation of concerns in our stack:
-
Authentication/Authorisation functions including storage of personally identifiable information such as social security (NIF), Phone Number, email, (hashed) password, IP address and location data, should be stored on a logically separate and highly secured database instance which regular engineers never need to touch. This adds much needed additional security for mitigating personal data breaches.
-
Business Logic is contained within the Web App which connects with Auth whenever a user data, roles or permissions query is required. All functionality described in the Technical Brief can (should) be built this way. All “Transaction data” (owned by the business) references a user_id owned by Auth service.
-
Analytics & Logging - the lifeblood of any business - is the 3rd separate service. We recommend running an instance of plausible.io or paying for the hosted service (€19/month), it includes all of the core features of Google Analytics without the privacy concerns of leaking personal data. Treating Analytics data as logically separate from Business Logic is best practice because it is not the core functionality of the business so the service should not impact response times of requests for a desk/booking.
-
Comms Service - We deploy a separate Comms Service for handling sending email and notifications. This uses 3rd-party service such as AWS or Twilio to handle the delivery. Having Comms separate from App means engineers never have the Twilio or AWS API Keys on their machine and cannot accidentally leak them (huge headache/cost). The App code just calls the service with a simple request: “Send Booking Confirmed email to user_id:123”.
-
API requests are handled by the Web App without incurring additional complexity; the same endpoints that render HTML can render JSON. The same Auth and WebSockets used by the Web App can be consumed natively by the Mobile Client. When the traffic volume justifies spinning up a dedicated API server, it’s simply an additional instance without any incremental devops overhead.
Todo
I've described the following separation of concerns in our stack:
Authentication/Authorisation functions including storage of personally identifiable information such as social security (NIF), Phone Number, email, (hashed) password, IP address and location data, should be stored on a logically separate and highly secured database instance which regular engineers never need to touch. This adds much needed additional security for mitigating personal data breaches.
Business Logic is contained within the Web App which connects with Auth whenever a user data, roles or permissions query is required. All functionality described in the Technical Brief can (should) be built this way. All “Transaction data” (owned by the business) references a user_id owned by Auth service.
Analytics & Logging - the lifeblood of any business - is the 3rd separate service. We recommend running an instance of plausible.io or paying for the hosted service (€19/month), it includes all of the core features of Google Analytics without the privacy concerns of leaking personal data. Treating Analytics data as logically separate from Business Logic is best practice because it is not the core functionality of the business so the service should not impact response times of requests for a desk/booking.
Comms Service - We deploy a separate Comms Service for handling sending email and notifications. This uses 3rd-party service such as AWS or Twilio to handle the delivery. Having Comms separate from App means engineers never have the Twilio or AWS API Keys on their machine and cannot accidentally leak them (huge headache/cost). The App code just calls the service with a simple request: “Send Booking Confirmed email to user_id:123”.
API requests are handled by the Web App without incurring additional complexity; the same endpoints that render HTML can render JSON. The same Auth and WebSockets used by the Web App can be consumed natively by the Mobile Client. When the traffic volume justifies spinning up a dedicated API server, it’s simply an additional instance without any incremental devops overhead.
Todo