Απορίες σχετικά με το CLI

Question

Στην ερώτηση αυτή συνοψίζονται αρκετές απορίες που μου έχουν δημιουργηθεί κατά την υλοποίηση του CLI:

1. Γνωρίζω πως το CLI επικοινωνεί με τη βάση ανεξαρτήτως του API, ως εκ τούτου, αφού επιτρέπεται να δημιουργηθούν χρήστες μόνο μέσω του CLI, γιατί είναι απαραίτητα τα διαχειριστικά endpoints? Θέλετε το CLI να χτυπάει το API ( άρα η υλοποίηση με απευθείας επικοινωνία με τη βάση είναι λανθασμένη) ή είναι πλεονασμός για την περίπτωση που τελικά θέλουμε να βάλουμε χρήστες και με requests?

2. Το API key είναι κάτι που αναφέρεται μόνο στην εκφώνηση του CLI. Είναι κάποιο αναγνωριστικό της εφαρμογής, το οποίο θα δημιουργήσουμε εμείς "με το χέρι" και απλά θα πρέπει να παρέχεται σε κάθε κλήση σαν διαπιστευτήριο για την κατοχή του "κλειδιού του λογισμικού" ή είναι κάτι εντελώς διαφορετικό;

3. Στο scope του Admin σε περίπτωση εισαγωγής της παραμέτρου --users λέτε πως θέλετε να εμφανίζεται η κατάσταση του χρήστη, ως τι ορίζουμε την κατάσταση του χρήστη; Είναι σωστό να εμφανίζουμε απλώς τα δεδομένα του (όπως ζητείται στο αντίστοιχο endpoint); Αν όχι μπορείτε να διευκρινίσετε σε τι ακριβώς αναφέρεστε;

4. Σε περίπτωση δεδομένων που χρειάζεται να παρουσιαστούν με ένα από τα 2 υποστηριζόμενα formats, θέλετε τα δεδομένα που επιστρέφονται να αποθηκευόνται με το αντίστοιχο format σε κάποιο αρχείο ή να εμφανίζονται στο terminal με αυτό;

5. Είναι πρόβλημα αν το token που φτιάχνουμε κατά το login αποθηκεύεται σε αρχείο στον κεντρικό φάκελο του project; Κι αν ναι, θέλετε να αποθηκεύεται στο home folder τοπικά στον υπολογιστή;

6. Σε περίπτωση Admin scope με παραμέτρους είτε --healthcheck, είτε --resetsessions, μπορούμε να κάνουμε ό,τι και στα αντίστοιχα scopes (απλώς απαιτώντας τώρα τη διαπίστευση επιπέδου admin) ή θέλετε κάτι διαφορετικό;

Σας ευχαριστώ εκ των προτέρων!

Answer 1

1. Γενικά η απευθείας επικοινωνία με τη βάση θα πρέπει να αποφεύγεται. Άλλωστε ο λόγος που υλοποιήσατε το API είναι για να το επαναχρησιμοποιείτε.

2. Είδα μια ερώτηση για το API key και σε ένα άλλο post, και είμαι 99% σίγουρος πως αναφέρονται στο token που θα κάνετε generate κάθε φορά που ένας χρήστης κάνει login στην εφαρμογή σας.

3. Μάλλον πρέπει να επιστρέφεις όσες πληροφορίες γνωρίζεις για αυτόν (αν έχει κάποιο active token, τα quotas του, ή οτι άλλο αποφασίσετε να καταγράφετε). Διδάσκοντας δεν είμαι, αυτά είναι απλά η προσωπική μου γνώμη.

4. Το καλύτερο σε τέτοιες περιπτώσεις είναι απλά να εκτυπώνεις τα περιεχόμενα. Αν ο χρήσης επιθυμεί να τα αποθηκεύσει σε αρχείο του το προσφέρει και το shell του. Σε περίπτωση που η έξοδος δεν είναι καθαρή (δηλαδή μόνο τα περιεχόμενα του αρχείο και τίποτε άλλο) συνηθίζεται να περνιέται έξτρα flag πχ --save για να σωθεί σε αρχείο τοπικά.

5. Δεν είναι καλή πρακτική, αλλά για τα πλαίσια του μαθήματος είναι ΟΚ.

6. Δεν καταλαβαίνω ακριβώς τι ρωτάς, αλλά τα operations που αναφέρεις κάνουν έναν έλεγχο για το αν το σύστημα είναι up & running, και το δεύτερο καθιστά μη έγκυρα όλα τα υπαρκτά tokens (κατά κάποιο τρόπο κάνει "logout" όλους τους χρήστες)

Answer 2

1. Γενικά η απευθείας επικοινωνία με τη βάση θα πρέπει να αποφεύγεται. Άλλωστε ο λόγος που υλοποιήσατε το API είναι για να το επαναχρησιμοποιείτε.
   ΒΒ> Σωστά! Πρέπει (ζητείται) να χρησιμοποιήσετε το API, οτιδήποτε άλλο είναι κακή αρχιτεκτονική (=λάθος).

2. Είδα μια ερώτηση για το API key και σε ένα άλλο post, και είμαι 99% σίγουρος πως αναφέρονται στο token που θα κάνετε generate κάθε φορά που ένας χρήστης κάνει login στην εφαρμογή σας.
   Σωστά!

3. Μάλλον πρέπει να επιστρέφεις όσες πληροφορίες γνωρίζεις για αυτόν (αν έχει κάποιο active token, τα quotas του, ή οτι άλλο αποφασίσετε να καταγράφετε). Διδάσκοντας δεν είμαι, αυτά είναι απλά η προσωπική μου γνώμη.
   ΒΒ> Επίσης συμφωνώ, αν και είμαστε ok με το όνομα του χρήστη και την κατάσταση του. Προσοχή: quotas δεν υπάρχουν, αυτό ήταν στο περυσινό θέμα και όπου έχει ξεμείνει η λέξη, είπαμε ότι δεν ισχύει.

1. Το καλύτερο σε τέτοιες περιπτώσεις είναι απλά να εκτυπώνεις τα περιεχόμενα. Αν ο χρήσης επιθυμεί να τα αποθηκεύσει σε αρχείο του το προσφέρει και το shell του. Σε περίπτωση που η έξοδος δεν είναι καθαρή (δηλαδή μόνο τα περιεχόμενα του αρχείο και τίποτε άλλο) συνηθίζεται να περνιέται έξτρα flag πχ --save για να σωθεί σε αρχείο τοπικά.
   ΒΒ> Στο πρώτο συμφωνώ. Το δεύτερο (προσθήκη flag) δεν ζητείται.

2. Δεν είναι καλή πρακτική, αλλά για τα πλαίσια του μαθήματος είναι ΟΚ.
   ΒΒ> Πράγματι!

3. ΒΒ> Είναι σαφές τι ζητείται και δεν υπονοείται τίποτε πλέον όσων αναφέρονται

Comments

1. Ουσιαστικά το CLI δεν συνιστά access point; Γιατί ένα access point να χτυπάει ένα άλλο; Σκεφτόμουν πως στην περίπτωση π.χ. που για κάποιο λόγο έχει πέσει ο server με αυτή την υλοποίηση δεν θα μπορούμε να έχουμε πρόσβαση στην εφαρμογή ούτε μέσω CLI, γι' αυτό και μου φάνηκε πιο λογική η υλοποίηση ενός CLI που επαναχρησιμοποιεί μεν τον κώδικα του API, αλλά πραγματοποιεί την εκάστοτε επιθυμητή λειτουργία ανεξάρτητα απ' αυτό. Για μεγαλύτερη διαθεσιμότητα. Μπορείτε να μου εξηγήσετε γιατί αυτό είναι κακή πολιτική; Θα φροντίσω να αλλάξω την υλοποίηση, απλώς θέλω να κατανοήσω από που πηγάζει το λάθος μου.

2. Όσων αφορά το APi Key, αφού είναι πιθανό ο χρήστης να χρησιμοποιεί το CLI χωρίς να έχει κάνει login (ακόμα και στο ίδιο το login χρειάζεται να δώσω το API KEY) πώς θα το γνωρίζω για να το δώσω;

---

Ενδιαφέρουσα ερώτηση και χρήσιμη για συζήτηση στο μάθημα.

Το CLI λειτουργικά είναι access point οπότε μία επιλογή είναι να θεωρήσουμε ότι το υλοποιούμε ανεξάρτητα από τα υπόλοιπα.

Ωστόσο, η συντήρηση μιας τέτοιας αρχιτεκτονικής επιλογής είναι δύσκολη. Αν αλλάξει κάτι στη βάση πχ, πρέπει να ενημερωθούν 2 δρόμοι μέχρι τον καταναλωτή του CLI / API αν έχεις ανεξάρτητες υλοποιήσεις. Αυτό σημαίνει χρόνος και περιθώριο για σφάλματα, όσο καλή διαχείριση του κώδικα και να κάνεις. Το αν η διαθεσιμότητα θα είναι μεγαλύτερη εξαρτάται από άλλα πράγματα: πού τρέχει το cli και πού το API.

Η δική μας ζητούμενη αρχιτεκτονική επιλογή είναι αυτή που έχουμε μόνο μία υλοποίηση της SQL (γενικά της άμεσης πρόσβασης στη βάση), αυτή του API.

Υπάρχουν tradeoffs, αλλά σαν πρακτική είναι κατά τη γνώμη μου πιο σταθερή και πιο συντηρήσιμη. Δεν είναι θέμα "σωστού" ή "λάθους".

---

2) Ο χρήστης δεν μπορεί να χρησιμοποιεί το cli χωρίς login. Πρέπει να κάνει login από το CLI.

---

1. Δεν είχα σκεφτεί καθόλου το κομμάτι αυτό, οπότε δεν μπορούσα καθόλου να δω το πιθανό πρόβλημα.

2. Όσων αφορά το API key, αναφέρεται ρητά στην εκφώνηση πως πρέπει να δίνεται σαν παράμετρος σε κάθε κλήση στο cli. Φαντάζομαι πως με βάση αυτό, θα πρέπει τελικά να το δίνουμε μόνο σε όσες κλήσεις απαιτούν κάποια διαπίστευση του χρήστη. Σε αυτή την περίπτωση είναι πλήρως κατανοητό το πως θα το χειριστούμε.

Σας ευχαριστώ για τις απαντήσεις, ήταν αρκετά βοηθητικές για να ξεκαθαρίσει η κατάσταση στο μυαλό μου.