Angular2: architettura di servizio + gestione degli errori

Ho bisogno del supporto per le architetture di servizio Angular2. Conosco abbastanza bene Angular2, ma non vedo il modo migliore per implementare servizi, gestione degli errori e la loro connessione con i componenti. Sto puntando a piccole e medie applicazioni Angular2 con non più di poche pagine (< 100).

Questi sono i miei principali dilemmi:

1. Funzioni osservabili RxJS OR Promise / async-await (o teoricamente callback, ma in nessun modo)
2. Propagazione degli errori: gestione degli errori nel servizio OR nel componente
3. I risultati di una chiamata di servizio devono essere disponibili per tutti O solo per il chiamante

Lasciatemi scrivere alcuni esempi.

export class StuffService {
  constructor(private http: Http, private alert: AlertService) {}

  // 1. RxJs
  // 2. Handling error in component (caller)
  // 3. Results for caller only
  getAll(): Observable<Stuff[]> {
    return this.http.get('/stuff/all')
    .map(res => res.json());
  }

  // Subscribe for this to get the results
  stuffs = new BehaviorSubject<Stuff[]>([]);

  // 1. RxJs
  // 2. Handling error in service
  // 3. Results for everyone 
  getAll2(): void {
    this.http.get('/stuff/all')
    .map(res => res.json())
    .subscribe(
      res => this.stuffs.next(res),
      err => this.alert.errorPopup('Refresh failed'),
    );
  }

  // 1. Async-await (Promise)
  // 2. Handling error in component
  // 3. Update results for caller only; and it also updates the 'stuffs' observable
  async update(item: Stuff) {
    let result = await this.http.post('/stuff/update', item)
    .map(res => res.json())
    .toPromise();
    // Auto-refreshing the list, each subscriber gets the update
    this.getAll2();
    return result;
  }
}

Preferirei sia la seconda che la terza soluzione.

A. Voglio mantenere alcuni dati disponibili globalmente attraverso le sottoscrizioni (vedi stuffs nell'esempio) perché previene le incongruenze: ogni volta che un componente aggiorna l'elenco viene aggiornato ovunque . E richiede una singola query. RxJs Observable s si adatta perfettamente a questo concetto.

B. In genere preferirei la gestione degli errori a livello di servizio, in questo caso: solleva un popup di errore modale dal servizio. Nella maggior parte dei casi è sufficiente e impedisce la gestione degli errori ridondanti in ogni chiamante. Ma cosa succede se abbiamo bisogno di gestione degli errori nel chiamante? Cosa succede se il servizio non deve alzare il popup?

C. Alcune opeazioni non dovrebbero interessare nessun altro oltre al chiamante. Può avere successo o fallire, e può influenzare il chiamante ma nient'altro. Questo è un tipico caso d'uso per Promises, RxJ sembra essere eccessivo in questo caso. La gestione degli errori è anche una domanda qui: in servizio o in chiamante? (Vedere il punto precedente.)

D. Alcune operazioni non influiscono direttamente su nessun altro, ma dovremmo eseguire un aggiornamento su altri dati, e questo influirà su molti altri. Vedi l'operazione update() : dovremmo aggiornare l'elenco stuffs dopo l'aggiornamento per ottenere le modifiche.

E. Mantieni il più semplice possibile. Questa non è scienza missilistica, solo un'architettura web specifica per domini semplice ed efficiente.

Questi dilemmi potrebbero facilmente portare a un disastro architettonico a lungo termine. Mi piacerebbe sentire le tue opinioni e le migliori pratiche.