Fornisce dati eterogenei dal back-end

Naviga le tue risposte
0

C'è un'applicazione che serve un enorme elenco di risorse e nell'interfaccia utente gli utenti sono in grado di filtrare le risorse in base al tipo e ad altre proprietà.

Le risorse sono di tipi diversi ma hanno poche proprietà comuni in esse. Ad esempio ci sono risorse di tipo Car , Book e Pet ciascuna ha colore, prezzo, proprietario e tipo come proprietà comune.

Attualmente l'applicazione ha un endpoint /resources che invia tutte le risorse contemporaneamente come JSON che è un elenco di oggetti risorsa, ora a causa di questo approccio quasi tutti gli oggetti hanno pochi campi con valori null e le proprietà che non ha alcun senso.

Prendiamo un esempio: 

[{
  type: 'car',
  color: 'red',
  price: '1000',
  owner: 'foo',
  engines: '2',
  tyres: '4',
  capacity: '2',
  name: null
},{
  type: 'pet',
  color: 'red',
  price: '10',
  owner: 'foo',
  engines: null,
  tyres: null,
  capacity: null,
  name: 'koo'
},{
  type: 'book',
  color: null,
  price: '1000',
  owner: 'foo',
  engines: null,
  tyres: null,
  capacity: null,
  name: 'theory of everything'
}, ...];

Una volta che i dati sono in primo piano, l'utente può applicare qualsiasi tipo di filtro per ottenere le informazioni richieste.

I problemi:

  1. Esiste una singola tabella dell'interfaccia utente e l'intestazione viene modificata in base alla risorsa mostrata.
  2. Il front-end ( typescript ) e il back-end ( java ) sono molto controllati e il codice basato sembra (è) ripetitivo e fragile.

Domande:

Il progetto è ancora in fase iniziale e quindi posso chiedere il refactoring che può fornire un guadagno a lungo termine, stavo pensando se ci fosse bisogno di punti finali diversi e quindi aggregarli nel front-end? ma poi ci sarebbero molte chiamate API per ogni tipo di risorsa e l'interfaccia utente potrebbe essere in stato incoerente se tutti i dati non riescono a caricare.

    
posta CodeYogi 13.10.2017 - 20:03
fonte

1 risposta

1

Un'applicazione può fornire un flusso di dati di oggetti di vario tipo, non c'è nulla di sbagliato in questo. Ma se le applicazioni per il consumatore devono rimanere robuste e mantenibili, è una buona idea assicurarsi che ciascuno degli oggetti presenti abbastanza metadati per consentire al consumatore di quel flusso di interpretare correttamente i dati in modo più o meno generale, senza un sacco di errori ipotesi implicite sulla struttura dei dati o sulla sua semantica.

Ad esempio, se l'unico scopo della tua idea di endpoint diversi è pre-filtrare gli oggetti per tipo, ma ognuno degli oggetti contiene anche informazioni di tipo esplicito come mostrato nell'esempio, quindi diversi endpoint non porteranno qualsiasi vantaggio in termini di manutenibilità, in quanto il consumatore può semplicemente filtrare l'oggetto in flussi diversi utilizzando il campo tipo, se necessario. Le informazioni sul tipo sono qui la parte importante dei metadati.

Oppure, se qui il caso d'uso principale è quello di consentire all'utente di filtrare le informazioni fornite da quel flusso di dati, l'informazione sui metadati dei nomi attributo / colonna è cruciale e viene fornita anche dal formato JSON. Se, tuttavia, i dati dovrebbero essere ordinati nell'interfaccia utente, è necessario conoscere il tipo esatto di dati degli attributi, poiché i numeri vengono ordinati in modo diverso quando interpretati come stringhe. Questi potrebbero essere forniti da uno schema JSON separato o rendendo i valori letterali sensibili al tipo (opposti al tuo esempio precedente, in cui ogni numero sembra essere codificato in una stringa).

    
risposta data 14.10.2017 - 06:03
fonte

Leggi altre domande sui tag

Qual è l'opposto del 'load factor' (in riferimento alle tabelle hash) T4 Template vs conversione manuale in C #