http://localhost:9090/api/webjars/swagger-ui/index.html
http://localhost:8080/content/upload/api/v3/api-docs
http://localhost:8080/content/upload/actuator/config
http://localhost:8080/user/private/config
Content-Upload | User | Issue# | |
---|---|---|---|
Clearly documented interfaces | (x) | (x) | https://github.com/Tyagi-Gaurav/Movie/issues/212 |
Resilience libraries configured for any downstream |
(x) | (x) | https://github.com/Tyagi-Gaurav/Movie/issues/194 |
Intra service communication via GRPC | (x) | NA | |
Public API only accessible on HTTPS | (x) | (x) | |
All Public API only accessible via API gateway | (x) | (x) | |
Healthcheck, Liveness Checks & Raediness Checks | (x) | (x) | https://github.com/Tyagi-Gaurav/Movie/issues/296 |
Application should shutdown gracefully | (x) | (x) | https://github.com/Tyagi-Gaurav/Movie/issues/159 |
Metrics Available for |
(x) | (x) | |
Ensure Sensitive fields are not printed to Console or logs. Eg. PII, Password, Secrets etc. | (x) | (x) | |
SLO documented for all services | (x) | (x) | (Can do as part of load test) |
flowchart LR;
A(Commit) --> B(Compile)
B --> C(Unit Test)
C --> D(Integration Test)
D --> E(Static Analysis)
E --> F(Build Image)
F --> G(Deploy Image)
G --> H(Remote Functional Tests)
H --> I(Load Test)
I --> J(Resilience Test 1 - Deployment while running load test)
To access the application, users need a valid userId
and password
to login. Once they login, they would be provided
a security token (JWT)
The application also supports login to App via Google and Github credentials. When the ui
container
is running locally, the page can be accessed via
http://localhost:8080/ui/index.html
There are three categories of tests available to execute.
./gradlew clean check
Integration tests: These are a set of slow running tests that spin up the entire application in memory before running the tests. They can be triggered separately using.
./gradlew clean integrationTest
Functional tests: The functional tests verify correctness of the application as a black box. Hence, they need the application to be running before they can be triggered.
To start the application, run the following command.
./gradlew clean build bootRun
or spin up the docker compose stack
docker-compose up -d --build
Once the application is running, the functional tests can be triggered using the following command.
./gradlew remoteFunctional
A code coverage plugin Jacoco has been added to the project in order to keep the test coverage in check. This plugin would automatically run whenever the unit tests are executed. The plugin generates an HTML report that can be found at the following path.
application/build/jacocoHtml/index.html
In order to run Jacoco separately, it can be triggered using the following command.
./gradlew application:jacocoTestReport
A postman collection has been added to the project if you need a more user-friendly way to explore the APIs of the
application. It can be found at the root directory of the project by the name of MovieAPI.postman_collection.json
The application can either be started in Standalone mode where everything runs in-memory or in the non-standalone mode where it could run inside a docker container.
./gradlew clean build bootRun
docker-compose up -d --build
In standalone mode, the application can be stopped by pressing Ctrl-C
. This would send a SIGTERM
to the application
that would terminate it gracefully. For application, running in docker container, use docker stop <container_name>
or
spin down the docker compose stack.
Once the application is running, it's important to be able to monitor the operations of the application. The following options are available monitor the application state.
status
endpointThis endpoint would help to determine if the application is available to serve its users. If the application is able to serve its users, it would return an HTTP status code of 200 with a text of "OK" as the response.
The application employs SLF4J api for logging. The properties for that can be found
under application/src/main/resources
. The default logging level has been set to INFO
.
For every request, the application assigns a unique request-ID and attaches it the request and response header. The request-ID appears alongside each log statement of the transaction and is also returned as part of the response. This should simplify any kind of request tracing that me be needed to perform.
For every request, the application also logs the total time it took for application to perform the operation. This time is also recorded into a histogram for easier analysis.
metrics
endpointJVM metrics can be accessed using an endpoint provided in the application. This would provide JVM metrics and all the other functional metrics provided in the application. The following metrics are available
request_latency
is a histogram to analyse endpoints latency.request_count
is a counter to record request counts for a given HTTP method and path.exceptionCount
ia a counter to provide the number of exceptions occurred by HTTP status code.The metrics endpoint can be accessed via the management port of the application. When running the app locally the URL
would be http://localhost:8081/actuator/metrics
. This would return a list of metric names.
To get details on an individual metric, we could use http://localhost:8081/actuator/metrics/<metricName>
.
The application runs on Java 17 which means that for application in standalone mode, it would need a Java installation. The application does not do that by itself.
For non-standalone mode, it just needs docker host and docker compose installations mentioned above.
[How do I?](./HowTo.MD#How do I?)
https://app.diagrams.net/#G1-Mc53tLb6Go2KNESpt4GowvgrouiGF2-