architecture for whitelisting clients

[John Grant]

Am I violating current practices with the following architecture?

1. on one subdomain/domain, a single service/module/app that defines entry point for all datastore access.
1. probably only has API, no html
2. probably in Python
3. users will need to authenticate for some data, but not all.
2. on multiple other domains or subdomains, statically hosted and served javascript front-ends (SPAs) will make https calls to the datastore service.
1. datastore service should manage data separately (multi-tenant) for some clients coming from different domains.
2. clients are probably hosted statically on various Cloud Storage instances

Some questions:

1. Is this the situation that Google Cloud Endpoints solves today (2016) or is that outdated technology? (I say outdated because the javascript client library does not offer Promise interface).
2. How should the datstore service whitelist the clients coming from different domains or mobile apps?
3. Can I enforce httpS is used when clients interact with datastore service?

Thank you for feedback.

John

[Adam (Cloud Platform Support)]

Google Cloud Endpoints isn't considered outdated. It's still the standard framework used to implement RESTful services on App Engine. The Javascript Client Library does support promises. The doc you linked to is a specific recipe for using AngularJS with Endpoints, but you are by no means limited to using AngularJS as your front-end framework.

[Adam (Cloud Platform Support)]

To answer your other questions, what you're describing doesn't sound like it's violating any best practices. Separating your back-end logic and exposing it as an API (a la microservices) is fairly par for the course.

Datastore supports multi-tenancy in the form of namespaces. HTTPS can be enforced on your API handlers using 'secure: always' in your app's configuration file (app.yaml). Whitelisting can be achieved using Cloud Endpoints's OAuth2 authorization (generally done using a web client ID for Javascript clients or an Android or iOS client ID for mobile clients).

On Monday, May 23, 2016 at 2:38:55 AM UTC-4, John Grant wrote: