Traduzioni dei messaggi nell'architettura dei microservizi

Question

Traduzioni dei messaggi nell'architettura dei microservizi

#1 da (3 voti)

2

Lavoro con un'applicazione web monolite scritta in PHP che viene migrata passo a passo nei microservizi. Mi piacerebbe mantenere la stessa interfaccia utente con diverse nuove funzionalità che sono state implementate durante la migrazione. Attualmente, i nuovi elementi dell'app sono scritti in Angular e comunicano con i microservizi tramite API REST per recuperare i dati e visualizzarli nell'interfaccia utente. Poiché il backed è suddiviso in più istanze con le proprie responsabilità, il frontend è ancora in "stile monolitico".

L'applicazione è tradotta in due lingue e ho iniziato a pensare dove mantenere le traduzioni dei testi ? È ancora responsabilità di un microservice (il client richiede le traduzioni di questa parte concreta ) o devo spostarlo nel client, dove è implementata l'interfaccia utente (il frontend sa come tradurre le cose da tutte le origini dati)?

Se sì (o meno), perché?

Grazie per qualsiasi suggerimento!

microservices internationalization

posta Kuba T 30.08.2016 - 21:49

fonte

1 risposta

Leggi altre domande sui tag microservices internationalization

Funzione C ++ (de) duplicazione in classi templatizzate Qual è il nome corretto per un flag / campo condizionalmente presente in un'interfaccia?

score 3 · Accepted Answer

Non c'è una risposta giusta o sbagliata; dipende interamente dai requisiti.

Chiedi a te stesso, cosa forniscono i microservizi e chi è incaricato di tradurre i dati puri in un formato leggibile, compreso il testo?

Facciamo un esempio di base di un'app che dice semplicemente ciao a un utente. Tuttavia, per fare ciò, è necessario chiamare un microservizio che restituisce il nome della persona in base al suo ID.

Il primo approccio consiste nel rendere il microservice responsabile dei dati e mettere l'app di consumo a capo della presentazione. Il servizio web restituirà semplicemente:
```
{
    "first-name": "Jon",
    "last-name": "Skeet"
}
```
mentre l'app web incorporerà questa risposta in un modello e la passerà alla vista che, alla fine, la trasformerà in un detto HTML ben formattato:

Hello, Jon Skeet!

o, se l'utente sembra utilizzare un'interfaccia francese:

Bonjour, Jon Skeet!

Vantaggio: i tuoi modelli rimangono in ordine, il testo effettivo tradotto viene applicato come ultimo passaggio. I modelli possono essere memorizzati nella cache indipendentemente dalla cultura dell'utente.
O forse il microservizio stesso sa come accogliere diverse persone. Alcuni sarebbero stati accolti in inglese, altri in francese; forse alcuni utenti non saranno nemmeno salutati, perché non hanno pagato i loro conti, e altri riceveranno un caloroso benvenuto, perché hanno uno status VIP.

In questo caso, il microservice tornerà piuttosto:
```
{
    "first-name": "Jon",
    "last-name": "Skeet",
    "greeting": "Welcome back, Jon Skeet!"
}
```
L'app web, d'altra parte, passerebbe semplicemente il valore /greeting così com'è alla vista per poter essere mostrata all'utente.

Vantaggio: i contenuti possono essere personalizzati in base alle informazioni disponibili per il microservizio. In caso contrario, il microservizio sarebbe costretto a fornire queste informazioni al consumatore, rendendo più complessa la logica del consumatore.