I need support for Angular2 service architectures. I am quite familiar with Angular2 but I don't see the best way to implement services, error handling and their connection with the components. I'm aiming at small-middle-sized Angular2 applications having not more than a few couple (<100) pages.

These are my main dilemmas:

  1. RxJs Observables OR Promise/async-await functions (or theoretically callbacks, but no way)
  2. Error propagation: handling errors in service OR in component
  3. Results of a service call shall be available to everyone OR only for the caller

Let me write a few examples.

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 {
    .map(res => res.json())
      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())
    // Auto-refreshing the list, each subscriber gets the update
    return result;

I'd prefer both the 2nd and 3rd solution.

A. I want to keep some data available globally through subscriptions (see stuffs in the example) because it prevents inconsistencies: whenever a component refreshes the list it gets updated everywhere. And it requires a single query. RxJs Observables fit to this concept perfectly.

B. Generally I'd prefer service-level error management, in this case: raise a modal error popup from the service. In most cases it is enough and prevents redundant error-handling in each caller. But what if we do need error handling in the caller? What if the service shouldn't raise the popup?

C. Some opeations should not affect anyone else besides the caller. It may succeed or fail, and it may affect the caller but nothing else. This is a typical use-case for Promises, RxJs seems to be an overkill in this case. Error-handling is also a question here: in service or in caller? (See previous point.)

D. Some operations do not affect anyone else directly but we should make an refresh on some other data -- and this will affect many other. See the update() operation: we should refresh the stuffs list after the update to get the changes.

E. Keep it simple as possible. This is not rocket science, only simple, efficient domain specific web architecture.

These dilemmas could easily lead to an architectural mess on the long run. I'd love to hear your opinions and best practices.

1 Answer 1


Depends on what you want to do in all three questions.

1.) I would suggest using Observables. I see no real reason to transform the observable to a promise.

2.)Is the data from the service incomplete? Did you recieve a wrong http code? Handle it in service.

Do you have a validator that wants to report this to the user, propagate the result to the component(Alert). Also dont forget that you can


3.) Depends again on what you want to do. Lets say you have a service that populates a single grid with data...it could only be available to that component.

On a side note, you could wrap everything, your whole class into a "caller" "remote" class. That way you dont have to include a dependancy on the http in every service. The service couuld have for example Post, Get, generate headers, create the request. Services can then communicate with your "wrapper" class instead of this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.