Dividing a large problem domain into independently developable and deployable modules requires an overall architecture POV.
This project is an attempt to create a viable framework for working in such a manner.
This project currently has two major parts. The first is the docker-compose.yaml
file found in the root folder. The second is in the hello-world-service
Within the docker compose yaml file there are currently two services configured. The first is a service known as traefik
and the other is a locally produced demo API (our own arbirtrary code)
This project is what is known as an API gateway. It is a server which monitors the cloud-hosting-environment for services and routes incoming traffic within the hosted application's network.
This allows a large number of servers running within a container-network to all appear on a shared domain URL externally.
In order to prove the functionality of redirected traffic we need a small number of arbitrary services. This first sample was created using the default nestjs hello-world template with an added dockerfile
In order to demonstrate the viability of other languages and frameworks a dotnet webapi
has also been included. The content of this one can be expected on the http://localhost/api/weatherforecast
endpoint.
This frontend is a simple create-react-app
template which lives at the root URL of the hosted site. important to note that this particular container couts as the DEFAULT landing page for the whole app, however other containers with more specific routes can override this landing.
- first ensure the containers ahve all been built using the command
docker compose build
from the root folder - run the overall command
docker compose up -d
in order to launch the "cluster" - verify that the system works as expected by loading the following urls
http://localhost
you should see a basic REACT pagehttp://localhost/nest
you should see "Hello World!"http://localhost/api/weatherforecast
you should see a json result
- to view the traefik UI load
http://localhost:8080
- refactor so the configuration of urls and endpoints is owned within the scope of the individual app subfolders as opposed to within the scope of a shared docker compose file.
- discover how to set up various containers within the cluster so they can reload on save/update - that way this setup can be used for a holistic development environment. (docker dev containers)
- figure out how to enable different front end pages dynamically (current challenge, different CSS files if referenced from a "root url" would likely reference the content of a different container)
- possible that requiring frontend pages not use relative paths is the only way to go?
- figure out certificate signing & TLS
- add authentication / authorization service, figure out how to have other hosted services consume the internal auth services.
- add "service mesh" layer for observability, logging, etc...
- reimplement in kubernetes
- figure out how to implement "subnetworks" or pod groups within individual microservices so they can have their own data persistence layer and more complex services (perhaps some microservices want event streaming or whatever)
- figure out how to manage secrets / variable configurations per environment.
- investigate the use of terraform / pulumi? any advantage to moving away from docker compose to a more robust infrastructure as code deployment tool?