This template contains five microservices:
- authentication-microservice
- user-microservice
- activity-microservice
- notification-microservice
- api-gateway
The authentication-microservice is responsible for registering new users and authenticating current ones, updating
passwords and deleting accounts. After successful authentication, this microservice will provide a JWT token which can
be used to bypass the security on the api-gateway and other microservices. This token contains the Username of the
user that authenticated.
The domain and application packages contain the code for the domain layer and application layer. The code for the
framework layer is the root package as Spring has some limitations on were certain files are located in terms of
autowiring.
The api-gateway routes paths and connects all the other microservices so that the user will have an easy way
of using the application. The gateway only contains endpoints that is used by every user on the platform. Administrative
endpoints such as add/edit/delete activity/boat/certificate and accept/reject user to certain activity are excluded and
available only on the related microservices. After the user has authenticated, they will have to create a profile. The profile creation is
done by making a request to the api-gateway, which is then routed to an endpoint in the user-microservice. The
profile consists of the following attributes: a name, a gender, an email address (optional), a preferred position, an
organization (for competitions), a field about whether he is an amateur or not, and a certificate (shall the user choose
to have the position of COX). To be able to add a certain certificate to the user, that certificate needs to be added to
the certificate database through user-microservice. The user can also specify the time at which he is available for
any kind of activity.
After the user has created their profile, they have the option of getting all the activities that they can join. Depending on the type of the activity, certain requirements must be met to be able to join. Firstly, a user can join if his preferred position has not been taken. Secondly, if the activity is a training the user must make a request to join with at least half an hour before the activity starts. If the activity is a competition, the user must be of the same gender that the other participants are, and he must make a request to join with at least a day before the competition. The user must also be in the same organization as the other participants to be able to join them in the competition. Lastly but not least, if the user has the position of a COX, the certificate he has must be of greater or equal weight than the one that the boat for the activity requires.
After the user sends a join request to an activity, the activity owner is notified and has the authority to accept or reject the applicant.
For users to be able to see updates that concern them, they must receive notifications. This is done in the
notification-microservice, where the user can choose what type of notifications he receives. The
notification-microservice is called by other microservices, for notifications of type: join activity, accept user
for activity and reject user for activity. As mentioned before, the user has the possibility to choose whether
they want to input an email address when creating their profile or not. This is done so that the user can have
an easier experience with receiving the notifications. If the user chooses not to input an email address,
we still want them to be able to see their notifications. Thus, a user can make requests in Postman to get and
delete their notifications.
Lastly, users can create activities. If the user creates an activity, he is automatically set as the owner. An owner can create a boat for the activity (that the participants will use), add/delete the boat, send notifications and change the date of the activity.
You can run the five microservices individually by starting the Spring applications. Then, you can use Postman to
perform the different requests. We have included a collection of postman requests for each endpoint. This can be found
under docs/requests. This json file can be imported to Postman and can be used directly to perform requests.
(Please keep in mind that you need to update the bearer token of the requests!)
We have left a list of requests that a user can make (to make it easier, we only put what comes after http://localhost:)
8080/register (POST)
8080/login (POST)
8080/auth/change (PUT)
8080/auth/delete (DELETE)
8080/user/create (POST)
8080/user/{username} (GET)
8080/user/{username}/name (GET)
8080/user/{username}/email (GET)
8080/user/{username}/gender (GET)
8080/user/{username}/organization (GET)
8080/user/{username}/certificate (GET)
8080/user/{username}/positions (GET)
8080/user/{username}/availability (GET)
8080/user/{username}/competitive (GET)
8080/user/email (PUT)
8080/user/name (PUT)
8080/user/gender (PUT)
8080/user/organization (PUT)
8080/user/certificate (PUT)
8080/user/positions (PUT)
8080/user/positions/add (PUT)
8080/user/positions/remove (PUT)
8080/user/availability (PUT)
8080/user/availability/add (PUT)
8080/user/availability/remove (PUT)
8080/user/competitive (PUT)
8080/user/delete (DELETE)
8080/activities (GET)
8080/activity/all (GET)
8080/activity/{activityId}/join (POST)
8080/activity/{activityId} (GET)
8080/boat/all (GET)
8080/boat/{boatId} (GET)
8080/notifications (GET)
8080/notifications/delete (DELETE)
8083/post/activity (POST)
8083/post/boat (POST)
8083/editActivity/{activityId} (PUT)
8083/deleteActivity/{activityId} (DELETE)
8083/deleteBoat/{boatId} (DELETE)
8083/editBoat/{boatId} (PUT)
8083/addBoat/{boatId}/toActivity/{activityId} (POST)
8083/deleteBoat/{boatId}/from/{activityId} (DELETE)
8083/deleteUser/{username}/{activityId} (DELETE)
8083/accept/{username}/{activityId} (POST)
8083/reject/{username}/{activityId} (POST)
8085/admin/certificates (GET)
8085/admin/certificates (PUT)