Background
Previously we completed our mobile theme by discussing Coding Key Points for the iOS app. Next we will begin a theme on modern deployment, and describe how the corresponding cloud infrastructure was created.
URL Design
Hosting should start with a URL design, and this blog uses a subdomain approach, to represent component separation on a small scale:
Domain | Description |
---|---|
https://web.authsamples.com | The Base URL for Single Page Apps |
https://api.authsamples.com | The API Gateway Base URL |
https://login.authsamples.com | The Authorization Server Base URL |
https://mobile.authsamples.com | Hosts assets for Mobile Apps |
Each subdomain can be a Serverless or Cloud Native endpoint. This blog will mix and match, depending on which option best meets our requirements.
DNS Setup
The AWS cloud is used, which starts with registering a parent domain of authsamples.com in Route 53:
Multiple internet accessible subdomains can then be registered as ‘A records’ under a Hosted Zone:
If you have your own cloud domain and subdomains, you could reconfigure this blog’s samples and deploy them there, with the same technical steps.
Managed Internet SSL Certificates
AWS Certificate Manager will issue TLS 1.3 certificates to our subdomains, using the same wildcard concept we’ve used on a local PC in earlier posts:
We will only have a single certificate to manage, and AWS will automatically renew it when it gets close to expiry.
Web and API Separation
The API base URLs support multiple microservices hosted behind the same API gateway:
The web base URL supports hosting multiple micro-frontends for the same business area:
SPA Deployment
The SPA deployment model will continue to be just static content, and we will just deploy our web resources to the web.authsamples.com S3 bucket:
We will then use AWS CloudFront as a Content Delivery Network:
Cloudfront pushes web content to many locations, to enable globally equal web performance, in a technically simple manner:
Serverless APIs
Initial cloud API endpoints will use the Serverless Framework. This enables us to host APIs at low cost, with minimal infrastructure to manage:
The AWS API Gateway will be the entry point for Serverless APIs:
Initial Cloud Authorization Server
Earlier in this blog we described AWS Cognito as an initial low cost authorization server. We will explain the AWS setup shortly:
Cloud Connected Code Samples
Use of cloud hosting enables any reader of this blog to run this blog’s OAuth code samples. Deployed endpoints are especially useful for mobile apps:
The Code Samples Quick Start page provides details of online URLs and guest credentials for running the demo apps.
Centralized API Logs
APIs will use this blog’s Effective API Logging design to write immediate log data to AWS Cloudwatch. These logs could then be aggregated to a managed Elasticsearch service. The Kibana tool would then be used to Analyse API Activity:
Serverless Costs
The AWS costs for the above setup (excluding Elasticsearch) are around 13 USD per year to register the base domain, along with a further 0.60 USD per month. This is an attractive option when getting started with cloud hosting:
Kubernetes Deployment
The API side of the architecture can also run in a Kubernetes environment. In AWS this would be managed by spinning up an EKS cluster, that hosts this blog’s final APIs, along with any suppporting components.
Where Are We?
We have defined our desired behaviour, and the following blog posts will describe some implementation details. In all cases our application code will remain portable so that it could easily be hosted elsewhere.
Next Steps
- Next we will cover details of our Cloud Domain Setup
- For a list of all blog posts see the Index Page