| # Fake SNS messages with VSCode REST Extension | |
| # Install this - https://marketplace.visualstudio.com/items?itemName=humao.rest-client | |
| @TOPIC_ARN = "arn:aws:sns:us-east-1:286528903076:BenTestTopic" | |
| ### | |
| # Fake SNS message subscription | |
| POST http://localhost:8000/sns/subscription | |
| x-amz-sns-message-type: SubscriptionConfirmation |
| from fastapi import FastAPI, Request | |
| from dotenv import load_dotenv | |
| import uvicorn | |
| import requests | |
| import os | |
| load_dotenv() | |
| app = FastAPI() |
| from fastapi import FastAPI, Request, status | |
| from fastapi.responses import PlainTextResponse | |
| import jwt | |
| import logging | |
| logger = logging.getLogger(__name__) | |
| app = FastAPI() | |
| @app.middleware("http") | |
| async def auth_middleware(request: Request, call_next): |
An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re building. Each ADR describes the architectural decision, its context, and its consequences. Many ADRs represent cross cutting concerns which will impact the project as a whole.
The ADR process outputs a collection of architectural decision records. This collection creates the decision log. The decision log provides the project context as well as detailed implementation and design information. Project members skim the headlines of each ADR to get an overview of the project context. They read the ADRs to dive deep into project implementations and design choices.
When the team accepts an ADR, it becomes immutable. If new insights require a different decision, the team proposes a new ADR. When the team accepts the new ADR, it supersedes the previous ADR.
This a collection of demo apps, all of which are aimed at for deployment as containers, mainly into Azure but could obviously run anywhere. These are designed for demos and hands on lab exercises, to be used with Azure and DevOps CI & CD scenarios, where you need "something" to deploy and push through the pipeline.
The apps are all small, simple standalone web applications but they are designed for ease of deployment, showcasing use of cloud native deployment scenarios and running as containers, rather than complete examples of a fully functioning architecture.
Example deployment scenarios
- Run locally
- Run as Docker container
- Run in Kubernetes & AKS
- Run in Azure App Service
- Run in Azure Container Instance & Container Apps