Jacoco

Add and configure JaCoCO to project for Test Coverages
Add JaCoCo Run to Github Actions (Don't fail PR's and commits, because tests need te be added progressively)

Badges

Add JaCoCo badges plugin to github Actions
Add JaCoCo badges to Readme

Extra's

Check for possibility to make more dedicated badges and add them to other things
Like badge of coverage of changed classes in PR?

References

JaCoCo
https://docs.gradle.org/current/userguide/jacoco_plugin.html

JaCoCo Badge Generator
https://github.com/marketplace/actions/jacoco-badge-generator

As a user I would like to be able to change email address, because:

• my mail address has changed
• I am locked out of my mail address and want to change it to a new one

Add ability to change email address in app.

As user
I want to be able to change my first name and last name on my account
So that i can be identified by others with my new name

Create a tactic/technique, split up, how we are going to test.

types

Unit test, test a small separated piece of code without the app context , the business logic
Integration service tests, test use cases and their possible paths, only test what can change and what is important in the service layer and flowthrough. Don't test every single unit case * security
consumer tests, test that the listener consumes specific event when it is published and calls/does the required logic. And in case of failure of logic then what
producer tests, test that a service publishes events when handled (and that the producer works)
Integration endpoint tests, test http requests en a set of possible security takes on the call.

Add security to tests where security plays a role:

• Create a way to easily test all roles.(common test fixtures of different user roles)
• Add test base for consumer test(logic publish request)
• add http/mock test base for http integration tests

• producer test (Service tested should publish event (into broker))
• Service integration tests / mocked tests
• Controller test base with http (mock) support
• user test fixtures

Goal

Create an IdReponse DTO class for controllers

Reason

IdResponses are used exactly the same in each service

Swagger-UI

Search if posible to do during runtime, or if a combined Swagger-docs file build is needed during build time

Create Swagger UI in Gateway that can show endpoint info of all underlaying services.

https://github.com/GnanaJeyam/microservice-patterns/tree/master/centralized-swagger-docs
^^^^^^^^^^^Voorbeeld (met Eurka servicediscovery ) van combined UI^^^^^^^^^^

Possibilities

• Make one page with all service endpoints
• Make page with Docker (dropdown) for each :
  controller
  Or
  (self-specified) set of endpoints (OpenAPI3 @group annotation or something?)

!!
Check if endpoints show the inside service URI or gateway URI.
This could create misunderstanding of endpoints otherwise.
If so check if the URI's shown can be configured (automaticly)
!!

References

https://stackoverflow.com/questions/63675544/springdoc-with-multiple-api-docs
https://springdoc.org/faq.html#how-can-i-agreagte-external-endpoints-exposing-openapi-3-spec-inside-one-single-application
https://swagger.io/docs/open-source-tools/swagger-ui/usage/configuration/

Refactor current implementation of get products of bar and get products of category id (with barid)
to a general get products of bar endpoint "/bar/{barId}/products"
with query parameters:

• category / categoryId
• isFavorite
• poductType / type
  Query parameters that could be implemented for broad usage of endpoint:
• min price
• max price
• size / amount (For easy quering of bottle / not bottle+ sized products)
• ??posibility?? search product by name/brandquery param
  (Add ability to search with aditional params, mentioned above) (i.e. search product name in category)

Goal

Find an easy way to version the api's

Posibilities

Version packages with copies of the api in them

package.v1.controller
package.v1.application

package.v2.controller
package.v2.application

Or, Versioned / proxied controllers/services

@OriginalEntpoint and input
v1controllerProxy(command) {
    v2controller.do( convertedCommand )
}

Versions

Versions can be determined by Major and minor versions
i.e. 1.3.2:: 1 is the major version, 3 is the minor version, 2 is the bug/patch update

Create a way of backwards &| backward compatibility

Other ways to version code

Create the person service

• Person: Boolean, preferred name (name or username or first + last name)
• Person Entity CRUD
• Person Entity Events
• Person User Entity
• User Event Consumer

Add the ability to change th user's password.
-> Endpoint to request change of password.
-> send email with temporary usable link/code/token to change password
-> change password on endpoint when token is valid

Goal

Make Database persistency versionable or forward compatible

Posibilities

Versioning database via patches on top of a base version

Make persisted classes forwards compatible

References

Base, Migration and Patches based DB versioning
https://weaintplastic.github.io/web-development-field-guide/Collaboration/Database_Versioning/The_Concept_of_Database_Versioning

Gateway

Efficiëntly configure Cloud Gateway

Problem

Eindpoint path routing for each separate controller in services
(that do not nest inside main uri, i.e. '/api/products/catagories')

Possibilities

Eindpoint:
Or, All registerd manualy (current)

Or, Has to be prefixed with recognisable URI part:

• i.e. '/security/authorization' and '/security/user'
• or, other way to register different controllers in a way to automaticly register them under the service URL

Or, Path rewriting

Or some other Automatic per service only URL registration

References

Spring cloud discovery?
https://stackoverflow.com/questions/60616745/what-are-the-differences-between-spring-cloud-gateway-and-eureka-service-discove
Netflix's Eureka discovery integration-dependency
https://www.javainuse.com/spring/cloud-gateway-eureka

Convert current CI pipeline into a separated test pipeline

Run Unit tests first,
Then the rest of the integration tests

Service health

Add Spring Actuator dpendency (application health endpoints)

Add Gateway ui endpoint to show all services's health.

Search for products base on given text

Product price versioning
Sla price history object op met current price en lijst van alle proces met dates.

^^met lazy loading, laadt dit dan alleen current price of laadt het de hele list prices?
Anders manier vinden om deze history te kunnen lossen via product maar niet altijd als je alleen current price wil

Of, sla price object op met date en vergeet directe ref van oude prijzen. Haal deze via repo op. Dit is alleen niet domain consistent en alleen via SQL prijzen ophalen
U

Category
-CRUD + GetAll

Add last bits of security module functionality, refactor, and tests

Redefine api enpoint adresses

Locations like /products/{productId}/bars/{barId} for a product of bar is a very bad uri or it contains request body with just bar id, which is very duplicate and not very REST succinct

map URIs to /bars/{barId}/resources/{resourceId}

• Bar
• Session
• Bill
• Category
• Product
• Security
• Gateway redirects

Maak nieuwe customer voor bar direct met info en connectie naar user account.

Dit bijv kunnen doen door klikken op add existing user knop
Dan drie mogelijkheden

User ID intypen
User(I'd) qr code scannen
User NFC:
User klikt op connect with bar(NFC), dit zet NFC aan met userid info
Bar owner houdt telefoon in add user NFC mode tegen telefoon van user

Add nieuwe user hiermee, met als preset ingevuld user info? Of gewoon leeg en puur id connecten

Misschien in backend nog iets toevoegen dat barowner niet random id's toevoegd en dat er een token moet worden meegestuurd, of dat de user juist connect door een qr link te openen(of via app invoken)
Dit zou wel betekenen dat user een tijdelijke link met een tijdelijk gecachte id called en dan uit z'n jwttoken of ophaalt en die aan user connect
Add dan user authorithy aan user account voor bar

Events (i.e. EntityCreated) are part of commands and queries,
is accessed in the application layer to publish, en thus should be placed in the application layer

• core
• bill
• product
• security

FIrst!

Before sending to a DeadLetterTopic, It can be a good idea to implement a retrying policy.
This means retrying /recovering+retrying a message in case of (certain specific) exceptions.
Like a timeout of another service/api or other recoverable + retryable exception.

DLT's can be use like this with a multi-DLT arrangement. or a index can be stored of which DLT message to retry later.

Add Deadletter topic for failed message handling.

When a message get processed on a faulty manner, creating an exception, it should be published to a Dead Letter Topic for later retrying.

Backoff

Repeat then drop trying to handle message.

• Start at retry after 5-50 ms (Snel opnieuw proberen)
• Multiply wait time by 10
• Repeat 5 times

Considerations

Order of processing messages in system could be the wrong order, due to failure in processing.
Check if Spring Kafka's DLT's handle this concurrency
or if an implementation of message offset should be stored
or if a way of redoing should be implemented (event sourcing with snapshots)

Add 2 factor authentication in the app
Posibilities:

• Email with code (expires after 5 min or so)
• Coupling with one or multiple existing 2FA apps (i.e. Google authenticator)

Goal

Create an IdReponse DTO class for controllers

Reason

IdResponses are used exactly the same in each service

Product
CRUD + Get All

Add the security annotations to all service methods

Service Registry

Deps

Spring boot eureka Server
Spring boot eureka Client

Goal

Add a Eureka registry service to register all services.
All services that can be deployed over multiple instances should use a single database per instance, because with our deployment, db per instance isnot needed

Banner

It can be fun to add a startup banner per application showing the application name.
As example. Security service startup shows asci big text 'Security'