nickdelta / hermes-backend Goto Github PK

Αυτό το issue επεκτείνει τα issues #3 και #4. Έχω ξεχάσει ότι για να δουλέψει σωστά ο DataProvider του Vaadin, χρειάζονται και endpoints που θα επιστρέφουν το συνολικό αριθμό των αιτήσεων σύμφωνα με τα κριτήρια αναζήτησης. Οπότε πρέπει να υλοποιηθούν τα εξής endpoints:

• GET /citizen/application/count

  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 200 ΟΚ - με σώμα τoν αριθμό
      ΠΡΟΣΟΧΗ: Πρέπει να επιστρέφεται ο αριθμός των αιτήσεων που ανήκουν στον συγκεκριμένο πολίτη που κάνει το αίτημα.

• GET /organization/application/count

  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 200 ΟΚ - με σώμα τoν αριθμό
      ΠΡΟΣΟΧΗ: Πρέπει να επιστρέφεται ο αριθμός των αιτήσεων που ανήκουν στον συγκεκριμένο οργανισμό που ανήκει ο υπάλληλος οργανισμού που κάνει το αίτημα.

Σημειώσεις:

1. Όπως καταλαβαίνεις πρέπει να τροποποιήσεις την συνάρτηση count() των JpaRepository και να βάλεις @Query με τη σωστή έκφραση σε κάθε περίπτωση.

Πρέπει να κατασκευαστεί το entity της αίτησης. Σύμφωνα με το HLD Document, η αίτηση πρέπει να περιλαμβάνει τα παρακάτω πεδία. Εδώ δίνονται και έξτρα πληροφορίες (τύποι, validation,κτλ):

Application extends AbstractEntity:

• ID (PK)
  • Κληρονομείται από το AbstractEntity
• ID πολίτη που κάνει την αίτηση
  • Το κληρονομείται από το AbstractEntity (createdBy στο auditing)
• ID οργανισμού στον οποίο καταθέτεται η αίτηση
  • String organization
  • @NotEmpty
• Κατάσταση της αίτησης (περιγράφεται παρακάτω)
  • (Enum) ApplicationState state
  • @NotNull
• Λεπτομέρειες σχετικά με την αίτηση
  • String details (μπορεί να είναι και empty)
• Timestamp δημιουργίας αίτησης
  • Κληρονομείται από το AbstractEntity (createdOn στο auditing)
• Ημερομηνία και ώρα που επιθυμεί ο πολίτης να γίνει η συνάντηση
  • Date appointmentDate
  • @Temporal(TemporalType.TIMESTAMP) (Επειδή θέλω να καταλαβαίνετε τον λόγο δείτε αυτό)
  • @Future (να είναι στο μέλλον υποχρεωτικά η χρονική στιγμή αυτή)

Πρέπει επίσης να κατασκευαστεί το Enum ApplicationState όπου θα περιέχει τις καταστάσεις που περιγράφονται στο doc μας. Δεν θέλω να σας δώσω 100% μασημένη τροφή οπότε δείτε τα docs του Hibernate και δείτε πως πρέπει να κάνετε map το enum.

Μερικές σημειώσεις:

• Δώστε όσα πιο πολλά metadata για το table μέσω @Column και @Table.

• Πρέπει να κάνουμε και μερικές βελτιστοποιήσεις στο σχήμα της ΒΔ μας. Μία από αυτές είναι η δημιουργία indexes για πεδία που χρησιμοποιούνται συχνά στην αναζήτηση. Όποιος αναλάβει αυτό το issue πρέπει να δει τις λειτουργικές απαιτήσεις και να δει για ποια πεδία πιστεύει ότι πρέπει να δημιουργηθούν indexes. Τι indexes ; Πώς τα δηλώνω στο Hibernate αυτά;

• Η οντότητα της αίτησης είναι auditable entity οπότε χρειάζεται αυτό το annotation : @EntityListeners(AuditingEntityListener.class)

Συνοπτικά,

• Πρέπει να προστεθουν manifests του k8s που να κάνουν deploy το backend στο GKE Cluster μας.
• Πρέπει να προστεθεί το Spring Boot Actuator για να έχουμε εύκολα και γρήγορα health checks για την εφαρμογή μας. Μέσω των έτοιμων readiness και liveness probes που δίνει, θα μπορεί πανεύκολα το k8s να εντοπίζει πότε το pod είναι έτοιμο να δεχτεί traffic και πότε δεν είναι υγιές. Το άρθρο αυτό εξηγεί πολλά : https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot. Προσοχή, τα endpoints του actuator πρέπει να έιναι εκτεθιμένα στη θύρα 9001 και όχι στην 8080 για να αποφύγουμε την έκθεση τους σε επίπεδο service.
• Πρέπει να προστεθεί ένα βήμα στο CI/CD Pipeline μας, το οποίο θα αυτοματοποιεί το deployment στο GKE. Η Google δίνει έτοιμο τον gke-deploy builder που διευκολύνει πολύ την διαδικασία για εμάς.

Πρέπει να υλοποιηθούν τα endpoints που θα καλεί το front-end κατά την αλληλεπίδραση του υπάλληλου οργανισμού με τις αιτήσεις του. To business logic περιγράφεται στο Functional Requirements & HLD doc.

Παρακάτω θα δωθούν κάποιες συγκεκριμένες προδιαγραφές για το REST API που πρέπει να υλοποιηθεί:

Όλα τα endpoints πρέπει να είναι προσβάσιμα μόνο από όσους έχουν τον ρόλο ROLE_ORG_EMPLOYEE

• GET /organization/application

  • Query Parameters:
    • offset (Integer)
    • limit (Integer) -> ουσιαστικά υποστήριξη Pagination
  • Returns:
    • 200 ΟΚ - με σώμα τις αιτήσεις.
      ΠΡΟΣΟΧΗ: Πρέπει να επιστρέφονται μόνο αιτήσεις που ανήκουν στον συγκεκριμένο οργανισμό στον οποίο εργάζεται ο υπάλληλος που κάνει το αίτημα.

• GET /organization/application/{id}

  • Returns:
    • 200 ΟΚ - με σώμα την αίτηση με το ζητούμενο id.
    • 403 Forbidden - αν η αίτηση υπάρχει αλλά ανήκει σε άλλον οργανισμό από αυτόν που δουλεύει ο υπάλληλος.
    • 404 Not Found - αν δεν υπάρχει αίτηση με το ζητούμενο id στη ΒΔ του συστήματος.

• PUT /citizen/application/{id}

  • Request Body:
    • Αντικείμενο Application (@Valid)
  • Returns:
    • 200 ΟΚ - αν η ενημέρωση της αίτησης έγινε επιτυχώς.
    • 403 Forbidden - αν η αίτηση υπάρχει αλλά αυτή ανήκει σε άλλο οργανισμό.
    • 404 Not Found - αν δεν υπάρχει αίτηση με το ζητούμενο id στη ΒΔ του συστήματος.

Μερικές σημειώσεις:

• Πρέπει να αποφασιστεί το πως θα ενσωματωθούν στοιχεία σχετικά με τους οργανισμούς στο token.
  Edit: Για να προχωρήσει αυτό το issue πρέπει να κλείσει το NickDelta/hermes-keycloak-image#2
• Προς το παρών δεν θεωρώ απαραίτητο να γίνει επαλήθευση της εγκυρότητας του business logic και στο backend (πχ δεν γίνεται από ακυρωμένη αίτηση κάποιος να πει οτι ξαφνικά ολοκληρώθηκε). Το front-end θα έχει αυτόν τον ρόλο. Αν στην πορεία κριθεί απαραίτητο, θα γίνουν αλλαγές στα services.

Αυτό το issue φέρνει τις εξής αλλαγές:

• Έγινε ένα bump στις εκδόσεις, συγκεκριμένα:

  • Bump Spring Boot σε 2.3.8
  • Bump Keycloak σε 12.0.2 (ως συνέπεια του NickDelta/hermes-keycloak-image#6)

• Ανανεώθηκε ο custom Keycloak Client (ως συνέπεια του NickDelta/hermes-keycloak-image#6)

• Συμμορφώθηκαν τα Repositories με τις αλλαγές του Keycloak Client

• Η εφαρμογή έγινε dockerized, φτιάχτηκε ένα μίνι pipeline στο Cloud Build και είμαστε έτοιμοι στο να τροφοδοτήσουμε το prod μηχάνημα μας με εικόνες

Πρέπει να υλοποιηθούν τα endpoints που θα καλεί το front-end κατά την αλληλεπίδραση του πολίτη με τις αιτήσεις του. To business logic περιγράφεται στο Functional Requirements & HLD doc μας. Οπότε είναι σημαντικό να το κοιτάς παράλληλα.

Θα σου δώσω κάποιες συγκεκριμένες προδιαγραφές για το REST API που πρέπει να υλοποιήσεις:

Όλα τα endpoints πρέπει να είναι προσβάσιμα μόνο από όσους έχουν τον ρόλο ROLE_CITIZEN

• GET /citizen/application

  • Query Parameters:
    • offset (Integer)
    • limit (Integer) -> ουσιαστικά υποστήριξη Pagination
  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 200 ΟΚ - με σώμα τις αιτήσεις.
      ΠΡΟΣΟΧΗ: Πρέπει να επιστρέφονται μόνο αιτήσεις που ανήκουν στον συγκεκριμένο πολίτη που κάνει το αίτημα

• GET /citizen/application/{id}

  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 200 ΟΚ - με σώμα την αίτηση με το ζητούμενο id.
      ΠΡΟΣΟΧΗ: Πρέπει να επιστρέφεται η αίτηση μόνο αν ανήκει στον συγκεκριμένο πολίτη που κάνει το αίτημα.
    • 403 Forbidden - αν η αίτηση υπάρχει αλλά o χρήστης δεν είναι ο ιδιοκτήτης της.
    • 404 Not Found - αν δεν υπάρχει αίτηση με το ζητούμενο id στη ΒΔ του συστήματος.
      ΣΥΜΒΟΥΛΗ: Τα 403 και 404 μπορείς να τα πετύχεις μαζί πολύ απλά χρησιμοποιώντας @PostAuthorize όπως έχουμε δει μαζί.

• POST /citizen/application

  • Request Body:
    • Αντικείμενο Application (@Valid)
  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 201 Created - με Location Header την τοποθεσία της νέας αίτησης

• PUT /citizen/application/{id}

  • Request Body:
    • Αντικείμενο Application (@Valid)
  • Returns (καλύπτονται μόνο οι περιπτώσεις που πρέπει εσύ να επέμβεις - άλλες γίνονται αυτόματα):
    • 200 ΟΚ - αν η ενημέρωση της αίτησης έγινε επιτυχώς.
    • 403 Forbidden - αν η αίτηση υπάρχει αλλά o χρήστης δεν είναι ο ιδιοκτήτης της.
    • 404 Not Found - αν δεν υπάρχει αίτηση με το ζητούμενο id στη ΒΔ του συστήματος.
      ΣΥΜΒΟΥΛΗ: Εδώ την λειτουργικότητα για τα 403 και 404 μπορείς να πετύχεις πανεύκολα βάσει κάτι που λογικά έφτιαξες παραπάνω. Σκέψου το καλά.

Μερικές σημειώσεις:

• Προς το παρών δεν θεωρώ απαραίτητο να γίνει επαλήθευση της εγκυρότητας του business logic και στο backend (πχ δεν γίνεται από ακυρωμένη αίτηση κάποιος να πει οτι ξαφνικά ολοκληρώθηκε). Το front-end θα έχει αυτόν τον ρόλο. Αν στην πορεία κριθεί απαραίτητο, θα γίνουν αλλαγές στα services.
• Όταν δεν βρίσκεις entity μέσω των Optional θα πετάς το δικό μας exception ResourceNotFoundException.
• Στο collection του postman θα βρεις έτοιμα τα endpoints που πρέπει να καλέσεις για να επαληθεύσεις αποτέλεσμα.
• Πρέπει να κάνεις καλό testing των endpoints τουλάχιστον για όσο δεν θα έχουμε automated unit testing (ελπίζω να καταφέρουμε κάποια στιγμή να εκπαιδευτούμε και το ενσωματώσουμε).