0

I am facing this situation:

I have a frontend which calls a REST endpoint to obtain some data and displays the data in a table.

For the frontend side, I am using Angular2 with Material design in Typescript.

I have a Service that was giving fake data while developing the frontend and now I am converting it to use angular Http service, to get the data from the actual backend.

this is an example kinda like the service I am using:

@Injectable()
export class ExampleService{
    getData(): Observable<DataType>{ ... }
    doStuffOnData(): Observable<boolean>{ ... }
}

Now, the results of getData() is injected directly into a DataSource which is fed to a MatTable, this way, when I was faking the backend, I could just return a BehaviourSubject and use next on each action that modifies the data.

Now that I am using the backend, first thing I did has been to send the Observable result of http.get directly to the table, and this works, but I don't know how to handle modifications.

Two possibilities come to my mind:

  1. Send a new GET request after each POST to retrieve the server-side updated data
  2. Cache the data in the service and modify manually after each successful request is made.

Does something else exist? Let's say I want to send a new GET, can I somehow get a "recurringGET" that I can send multiple times and it gives me the results always on the same observable? Something like:

@Injectable()
export class ExampleService{
    getData(): Observable<DataType>{ return http.recurringGET(); }
    doStuffOnData(): Observable<boolean>{ http.reissueGET(); }
}

I also fully control the backend, so if a smart solution needs to change the return of the call, it can be done. The backend is in raw PHP (yeah, painful, but the only possible solution given my hosting)

bracco23
  • 2,181
  • 10
  • 28
  • What you mention (recurring GET) is/was called long polling (https://stackoverflow.com/questions/333664/how-do-i-implement-basic-long-polling). But I don't know if this is still used. A better approach is to use websockets. – Christian Benseler Oct 10 '17 at 17:50
  • can you elaborate more? how can websocket fit into the situation? – bracco23 Oct 10 '17 at 17:52
  • With websockets you would create a "reactive" flow: instead of the frontend request every X amount of seconds for data (and then probably most of the times the respone won't have new data), the backend would be responsible to send/push the data to the frontend via socket (that is, in simple words, an "open gateway" between these 2 layers). – Christian Benseler Oct 16 '17 at 18:59
  • 1
    @ChristianBenseler i like your solution but unfortunately it is not good for me for two reasons: the data are modified only by the frontend itself, so data would get back from the server only after each request and not on their own will, and I have implemented the backend in PHP on a shared hosted site, so I guess websockets, if possible, would be really difficult. Solevd with the same method as now accepted answer, but thanks – bracco23 Oct 16 '17 at 19:03

1 Answers1

0

You should take a look at rxjs Subject. What you could do is store a privat dataSubject in your service and emit get/post data to it. eg.

import { Subject, Observable } from "rxjs";
import 'rxjs/add/operator/catch';    

@Injectable()
export class ExampleService{
private _dataSubject = new Subject()
    constructor(){
       // get initial data
       someHttpCall()
            .map(data => this._dataSubject.next(data.json()))
            .catch(err => this._dataSubject.error(err.json()))
    }

    getData(): Observable<DataType>{ return this._dataSubject; }
    doStuffOnData(): void{ 
       someHttpCall()
            .map(data => this._dataSubject.next(data.json()))
            .catch(err => this._dataSubject.error(err.json()))
    }
}

Then in your component you only have to subscribe to ExampleService.getData(), and when you call doStuffonData, the data is emitted to _dataSubject and the previous subscription will receive the data.

Andresson
  • 1,257
  • 10
  • 15
  • I guess this assumes that the POST calls echoes me back the modified data. Right now it doesn't, it gives me back a boolean (succeeded/not succeeded). Should I change the API? What is the usual behaviour in other REST APIs? – bracco23 Oct 10 '17 at 18:54
  • Yes precisely, well what is best practise I can't answer that but my personal experience tells me that returning the posted object is more beneficial than returning boolean. But you choose what fits your application the best. – Andresson Oct 10 '17 at 19:41
  • 1
    looked up and yes, return the state of the object is indeed the best thing according to REST principles, so did that and implemented your solution. Works fine. – bracco23 Oct 16 '17 at 19:05