Sta usando REST consumato da un framework Javascript sul front-end lo stesso che usare i microservizi?

Question

Sta usando REST consumato da un framework Javascript sul front-end lo stesso che usare i microservizi?

#1 da (2 voti)
#2 da (0 voti)

3

Ho un'applicazione monolitica. È MVC, PHP, tutto su un server. Viene copiato su un altro server o replicato. Esistono anche vecchie pagine Web che si connettono a database che non sono affatto correlati all'app MVC, aggiungendo complessità.

Non ho una grande squadra. Non ho bisogno di grandi team di vari settori per produrre un microservizio. Ma ho un sacco di database che devo interrogare e riportare tali informazioni in una singola pagina web, trasparente per l'utente. Non solo tabelle, interi database.

Sulla mia applicazione, il back-end, ho IIS, per esempio, e l'applicazione ha vari modelli che ottengono le informazioni dai database. Nel corso del tempo, questi modelli si gonfiano, o il controller lo fa. Il refactoring deve avvenire (questa è comunque la mia esperienza.)

Questo sistema è più vecchio e occorre aggiungere nuove cose, molte cose. È sufficiente giustificare una nuova applicazione web.

In questa nuova applicazione, se voglio usare JavaScript sul front-end che utilizza un'API REST, la combinazione di queste API REST è la stessa di "Microservices"?

Oltre a un possibile disordine, che tipo di architettura sto spiegando? Voglio utilizzare REST perché, oltre a me stesso, utilizzo l'API, altri possono anche. Posso semplicemente restituire JSON a loro (e alla mia applicazione).

EDIT: qui, link , una delle affermazioni che Martin Fowler fa diverse volte è: "Con un monolite qualsiasi modifica richiede una compilazione completa e l'implementazione dell'intera applicazione. " Cosa significa questo? Se costruisco un'applicazione web e cambio un titolo, non ricostruisco nulla. Io ora è semplicistico, ma diciamo che ho un modello, cambio il mio SQL per ottenere una nuova colonna. Ho messo un nuovo bit di Javascript e HTML e ho finito. Non sto dicendo che va bene, solo che succede, e non sono sicuro del motivo per cui ciò che Martin Fowler dice qui riguarda me.

design api design-patterns rest

posta johnny 01.12.2016 - 18:49

fonte

2 risposte

0

Una chiamata API può essere RESTful, parte di un'architettura di micro service (uno o l'altro), nessuno dei due o entrambi. Sono termini diversi che significano cose diverse.

RESTful significa conforme ai principi REST. Ad esempio, le chiamate basate su risorse, piuttosto che le chiamate basate sulla procedura.

I micro servizi essenzialmente riducono le grandi funzionalità in pezzi più piccoli, più gestibili e riutilizzabili.

risposta data 01.12.2016 - 19:44

fonte

Leggi altre domande sui tag design api design-patterns rest

Flusso di lavoro quando si utilizza il codice generato Dove si trova la documentazione di OpenSSL?

score 2 · Accepted Answer

Stai facendo le domande giuste. L'utilizzo di Servizi REST e JavaScript non rende un microservizio.

Martin Fowler ha un articolo che tenta di definire le caratteristiche di ciò che costituisce un'architettura di Microservice. Vale sicuramente la pena leggerlo perché mi ha chiarito molte cose su questo argomento.

Per riepilogare l'articolo (per quelli TL; DR orientato):

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

I vantaggi dei microservizi rispetto alle applicazioni monolitiche:

the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .