Would like to send message from backend nodejs app to frontend angular js via apigee

Not applicable

I couldn't see any option of using websockets in apigee so i'm planning to go with the httpserver. In Client (front end using angular js) planning to create httpserver and listen for particular port and in the backend system will send the http request message to the above listen port. Can anyone tell do we have any other better approach and also i dont have an idea on how to create http server in angular and listen the port(as it is a client side framework). Please don't refer any other link i didnt get clarified with any of the existing comments. Also our company decided to not use the microgateway so ignore if there is any option on this. I'm working in the private cloud deployed in our company.

Solved Solved
0 2 1,314
1 ACCEPTED SOLUTION

wat?

Can you explain with a diagram, even ascii art, how the various pieces are connected and where you are imagining Apigee Edge would fit?

Angular is a client framework. I don't know very much about angular, but I do know that it is used for clients, and you cannot create a server and listen for inbound requests when using angularjs in a client-side app.

The way you get information into single-page webapp clients (including clients using a framework like angularjs) is:

  • the client sends a request to a server
  • the server sends a response
  • the client reads the response.

This model is inherent in the definition of the terms "client" & "server."

You mentioned websockets. As you know, Apigee Edge does not support websockets.

I suggest you try one of two alternatives:

  • polling
  • long-polling

The first means: the client periodically (And perhaps asynchronously) checks for updates on the server. This might be accomplished with a timer in angularjs. For example, see this stackoverflow answer . The code looks like this:

var retryTimeInMilliseconds = 1500;
var promise =  $interval(function(){
$http({
        method: 'GET',
        url: '/foo/bar/my_target', 
    })
    .success(function(data, status, headers, config) {
        console.log(data)
    })
}, retryTimeInMilliseconds); 

The url in question is subject to Same-Origin policy, which means the target endpoint will need to be on the same server that served the webpage, or it will need to support CORS.

Long polling is basically the same idea, except the request remains outstanding for a long period and the interval in the client between subsequent requests might be shrunk to 10ms. Basically polling and long-polling have reversed wait-in-client and wait-in-server times:

pollinglong polling
wait in clientvaries, 1000ms or more typicallytypically quite short, maybe 10ms or even 1ms
wait in serverzero. If the server doesn't have data ready, it responds with 200 OK or 204 No Content.varies. Typically 60s or more. Requires the client timeouts be set appropriately.

View solution in original post

2 REPLIES 2

wat?

Can you explain with a diagram, even ascii art, how the various pieces are connected and where you are imagining Apigee Edge would fit?

Angular is a client framework. I don't know very much about angular, but I do know that it is used for clients, and you cannot create a server and listen for inbound requests when using angularjs in a client-side app.

The way you get information into single-page webapp clients (including clients using a framework like angularjs) is:

  • the client sends a request to a server
  • the server sends a response
  • the client reads the response.

This model is inherent in the definition of the terms "client" & "server."

You mentioned websockets. As you know, Apigee Edge does not support websockets.

I suggest you try one of two alternatives:

  • polling
  • long-polling

The first means: the client periodically (And perhaps asynchronously) checks for updates on the server. This might be accomplished with a timer in angularjs. For example, see this stackoverflow answer . The code looks like this:

var retryTimeInMilliseconds = 1500;
var promise =  $interval(function(){
$http({
        method: 'GET',
        url: '/foo/bar/my_target', 
    })
    .success(function(data, status, headers, config) {
        console.log(data)
    })
}, retryTimeInMilliseconds); 

The url in question is subject to Same-Origin policy, which means the target endpoint will need to be on the same server that served the webpage, or it will need to support CORS.

Long polling is basically the same idea, except the request remains outstanding for a long period and the interval in the client between subsequent requests might be shrunk to 10ms. Basically polling and long-polling have reversed wait-in-client and wait-in-server times:

pollinglong polling
wait in clientvaries, 1000ms or more typicallytypically quite short, maybe 10ms or even 1ms
wait in serverzero. If the server doesn't have data ready, it responds with 200 OK or 204 No Content.varies. Typically 60s or more. Requires the client timeouts be set appropriately.

Thanks for the response. i will check and get back if there is anything required.