![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="512" height="512"><rect fill-opacity="0"/></svg>){kind=avatar}
Exercise: Leadspotr Architectural Design
Now that you've seen an overview of the Leadspotr app, it's time for a small exercise: fill in the COSI worksheet for the Leadspotr app. You can find the worksheet in the downloads section of this lesson (it's right at the top).
Since at this stage we only covered the various architectural patterns on a surface level, this exercise is just aimed at getting you started thinking alongside the COSI dimensions. We'll revisit this analysis in the next module of this course. At the end of that module, you'll be asked to rework the COSI analysis of Leadspotr. You can then also see an example of how I filled in the COSI worksheet, so you can compare my analysis with yours.
Finally, I can't overstate this enough: the way you get the most out of this course is by getting actively involved. You might be tempted to skip exercises and quizzes and simply watch the videos. However, doing exercises like these will really help you organize your thoughts and get a better grip on what you need to think about when making architectural decisions. So, make sure you give this a try before moving on to the next lesson!
Communication - REST api with email server
Organization - Event-driven architecture and client-server (don't know whether serverless or not)
Storage - sql for everything except the pdf files. file-based storage for pdf files on server
Implementation - For general use, on-cloud (either dedicated server or serverless). If a company wants to host on-premises, then dedicated server on-site
Security - Password-based authentication
Privacy - For total privacy of specific client, at cliient's site, else, on cloud
Nice overview! In terms of security, have you thought about access management?
# Communication
- REST API Frontend Backend
- HTTP messages
- RabbitMQ for mails Send mail service and Sender
# Organization
Client-server
Backend true RESTapi like FastApi
Frontend in Next,js
# Storage
Backend communicate with SQL like PostgreSQL
# Implementation
- Docker
- Gitlab
- CI/CD Jenkins
- Small server for the beginning
- TDD approach
# Security
- username and password / login via gmail ect like https://next-auth.js.org/
- AuthO with JWT strategy
- Captcha on frontend as bot firewall
- of course passwors encrypted ect.
Nice design overview!
Just curious, why did you decide on using FastApi as the REST API backend instead of using Next.js fully?
In such architecture we could hide all rest APi behind server function in NEXT.js And Python is more flexible to use, easer to maintain vs always changing npm stuff.
This is some compromise because I want use react but with react problems solved by next - like routing httpOnly cookies ect.
And to avoid CORS
Alright! Sounds like a good plan! Thanks for clearing that up for me!
Hope you are enjoying the rest of the course :D
Communication
-------------
REST API (frontend <> backend)
TCP sockets (backend <> database)
SMTP mail (send quiz results)
Organization
------------
Client-server architecture
Backend is event-driven. After a quiz is completed, a task is enqueued for processing and generating quiz results.
Frontend is monolitic - a single-page application.
Storage
-------
Relational database to store companies, users, quizz details. s3 to keep quiz results (PDFs).
Implementation
--------------
Cloud hosting (AWS App Runner or Google Cloud Run).
Cloud-hosted database.
Security
--------
Oauth login, email / password login, passwordless login.
Privacy
-------
Encrypt sensitive data (passwords / auth tokens).
Processes
---------
Unit tests
End-to-end tests
CI / CD
Nice overview! Can you elaborate on why the backend is event-driven? Just curious to hear your thoughts!
# COMMUNICATION
- HTTP (API Rest)
- A Mail Client (SES)
- DB Connection(s)
# ORGANISATION
- Client-Server (Frontend & Backend)
- The Backend can be a Monolith, but depending on my last 'point' of the Event-Driven approach, it could be service-oriented as well.
- The Backend 'code' can be organized in a Hexagonal or Multi-Layer Architecture
- You can implement an Event-Driven approach for finishing a Quiz. So that multiple processes can react based on those events such as; generating PDFs, sending emails, generating statistics, etc (RabbitMQ/Kafka).
# STORAGE
- SQL Database (Postgres)
- Object storage for generated PDF files (S3)
- Store ongoing quizzes on-device, for easy and fast back-and-forth between questions.
# IMPLEMENTATION
- Docker
- Managed Database Provider (RDS)
- Run the Application on the Cloud
- Leverage Serverless at the beginning (Lambda)
- CI/CD (GitHub Actions probably)
As a side note; I tend to build all my projects using FastAPI with Mangum. This way, I keep the routing implementation on my end, but this allows me to leverage the quick and cheap cloud infrastructure from AWS Lambda. If my side project is never actively used, I don't pay money for my idle Cloud Infrastructure. If things blow up, I can easily remove Mangum from the project and start leveraging other services for managing my Cloud Infrastructure differently.
Looks like a good overview! Interesting to hear about Mangum, I have never used that before. It is super good that you are thinking about budgeting and handling being independent from cloud providers!
Do you have any other tips and tricks for becoming more independent of cloud providers?
Good question, and not really when it comes to the Cloud Services that I use. I try to keep the Application itself flexible so that I can move it between different Services whenever I want to (ECS, EKS, Lambda, EC2, etc).
But I've never really switched Cloud Providers, to be honest.
Thanks for your input!
I have never done it myself either, but I have noticed more of a trend of becoming more and more independent on which cloud provider that can be used
# Communication
- API REST
- HTTP messages
- AMQP to events (RabbitMQ+Celery+Flower/Kafka/NATS)
- SMTP to emails
- Pools of connection with the database
# Organization
- Client-server
- Monolith (in the beginning)
- Backend
- Frontend
- SQL Database
# Storage
- SQL Database (main and replica)
- NoSQL Database (cache)
- The project deals with quiz features on the creator side, and personal information (like email) on the response side.
# Implementation
- Docker images: back, frontend, in database in development
- Database as service em stage and production
- Cloud server
# Security
- Create user groups for authorization and authentication
- Basic Auth and JWT
- Captcha
# Privacy
- Data stored in a cloud database with different levels of authorization
- Hash emails or other personal information like cellphone
# Processes
- TDD
- Unit, integration, end-to-end, and load tests
- CI/CD
- Branches: features, development, stage, and production.
Great overview Miquéias! Is there a reason why the project will be monolithic in the beginning and then later changed?
It's a practice that I have used in all my new projects. I start with a monolith, and if the features start to grow, I begin to think of breaking into separate services and always keeping in mind the integration and complexity of everything.
Nice that you have found a way that works for you. Just for practice, have you tried not doing a monolith at the beginning? Could be a good learning opportunity to start with for example microservices right away