Closed
Milestone
Apr 16, 2023–May 7, 2023
Milestone 3
Milestone ID: 689
-
The REST API developed in M1 needs to be connected to the service and persistence layer developed in M2 for all the microservices (depending on the number of team members remaining in your team this might apply to a more limited set of services); -
Set up OAuth 2 Resource Server protection using Spring Security for your API. Reuse the client_id and client_secret for both the client and resource servers, and the test_* scopes from Seminar 09. Use different scopes for different methods where it makes sense. (The client is registered for http://localhost:8080 only, the authorization server will not redirect back to other locations. Use the client just to get an access token, no need to implement the UI); -
Use at least 2 different scopes; -
Each service must expose actuator health, metrics; -
Your systems will collect the metrics in an automated way (e.g., Prometheus); -
You must have a monitoring dashboard (e.g., Grafana) showing the state of your system; -
Define at least one runnable scenario to showcase the system: think about simulated number of users accessing the services with some specific goals - You can do this by implementing a script or using tools such as locust.io (https://locust.io/), JMeter (https://jmeter.apache.org/), or any platform that can be useful to represent users' behaviour; -
Describe in the README the scenario and the goals (e.g., showcasing high loads on one service during peak times) and what are the expected results; -
The README must contain all the instructions to run the application and the provided runnable scenario (i.e. for a script: the script itself and instructions on how to run it); -
(NEW) There must be a way to seed and clear the databases of your microservices. The data should also look somewhat realistic (no "AAAAAA" for names etc.) -
(NEW) Merge requests now require Approval of at least 2 members (set up your GitLab this way), the idea of using merge requests is not to create a branch, push code and merge to master. It should establish common code style and help code understanding within the team.