API e un client API condiviso

2

Siamo un tipo di avvio di un progetto che ha funzionato abbastanza bene e poiché tutte le startup l'obiettivo principale era quello di iniziare al più presto. Abbiamo realizzato il nostro progetto come un'applicazione monolite (PHP) che ha 4 sotto-applicazioni, ma ne richiederà di più in un paio di mesi. Abbiamo deciso che è ora di passare ai microservizi prima che sia troppo tardi, quindi proviamo a separare questa applicazione in piccoli pezzi come:

  • API
  • CRM
  • Lavoratori
  • Frontend
  • altri sottoprogetti, qualcosa tra frontend e CRM.

Attualmente il progetto è qualcosa di simile a MVC (ho capito che non è un MVC in PHP, ma diciamo che è così). Abbiamo Routing, Controllers, Views e sul livello del dominio abbiamo Repository & Entità.

Le entità non sono usate come oggetti di valore grezzo, ma anche se sanno dei loro figli, diciamo che se abbiamo un'entità $user , sa come $user->getArticles() recuperare gli articoli che appartengono a quell'utente. (Utilizza i repository qui).

I servizi comunicano utilizzando il formato JSON e il protocollo HTTP e non AMQP.

Ogni servizio risiederà sul proprio nodo, tutti i nodi saranno su una rete e questa domanda non riguarda le prestazioni quindi non ne parlerò più a lungo.

Il problema è che tutti i servizi devono comunicare con l'API e ci piacerebbe molto lavorare con le entità.

Personalmente, penso che il modo giusto sarebbe di migrare le entità in un sottoprogetto condiviso come APIClient e usarlo come un pacchetto di compositore in tutte le parti del progetto.

Nonostante ciò, penso che ci siano molte sfumature qui, come mantenere la versione corretta del client API per ogni progetto.

Domanda: Qual è il modo corretto per condividere oggetti entità e utilizzare un'API come unica parte del progetto che comunica con il DB?

Forse sto pensando troppo ed è più facile creare entità separate per ogni progetto, cioè solo entità e funzionalità di cui ha bisogno e fare in modo che il client API restituisca solo JSON / array / stdClass?

Forse qualcuno potrebbe collegarsi a una "storia di successo" su questo argomento, ma in relazione con PHP?

Spero davvero di aver fatto la domanda chiaramente. In caso contrario, permettimi di spiegare le parti che non hai compreso.

Modifica: ho disegnato questo diagramma, forse sarà più chiaro il motivo per cui mi piacerebbe che le entità fossero condivise.

  DB
   |
Repository
   |
 Entity ----|
   |        |
  API       |
   |        |
   |        |--------|
[ HTTP ]    | Shared |
   |        |--------|
   |        |
API CLI     |
   |        |
 Entity ----|
   |
do stuff
    
posta Sergey Telshevsky 10.11.2015 - 09:06
fonte

1 risposta

1

Sto avviando un progetto simile che comporta la gestione dei dati da diversi client (amministratore, intranet del client, front-end e API)

Nella mia progettazione, ho spostato TUTTA la logica in un livello chiamato servizio, che verrà istanziato in ciascuno dei client.

Non stiamo comunicando con il livello di servizio tramite http, ma istanziando il "userService" / "authenticationService" ovunque e su ogni client che ne ha bisogno.

Tutte e 4 le app sono nello stesso progetto, quindi le prestazioni sono incredibilmente veloci.

Con questa struttura, l'UserController nell'app front-end si limita a instradare UserService e chiama un metodo come - > UserService- > getUser ();

La cosa buona è che nessuno dei client deve preoccuparsi di come ottenere i dati, perché tutta la logica è mantenuta nel servizio.

Non sono sicuro se mi spiegassi bene, almeno ci ho provato.

    
risposta data 10.11.2015 - 10:22
fonte

Leggi altre domande sui tag