Deploying GraphQL (NodeJS) in Apigee

Not applicable

We're deploying a GraphQL service written in NodeJS in Apigee.

What is the best practice on reaching target endpoints?

Is it okay for my GraphQL services to reach target endpoints via Apigee proxy services?

or since I'm calling within the context of a NodeJS proxy, I'm better off calling the end point directly?

I'd prefer to call into Apigee endpoints.

Solved Solved
0 5 3,544
1 ACCEPTED SOLUTION

In Apigee, a Node JS application is a Target in itself. As such, the typical pattern is to call the endpoints directly. Any traffic management, caching, analytics and security policies can be added to the Request and Response flows of the proxy. This means they will be executed before or after the Node JS application. In my experience this is usually sufficient.

If you have a specific use-case that you think requires something different, please provide more detail so we can discuss. In the worst case scenario you can call back into Edge from Node JS, but this adds unnecessary latency.

View solution in original post

5 REPLIES 5

In Apigee, a Node JS application is a Target in itself. As such, the typical pattern is to call the endpoints directly. Any traffic management, caching, analytics and security policies can be added to the Request and Response flows of the proxy. This means they will be executed before or after the Node JS application. In my experience this is usually sufficient.

If you have a specific use-case that you think requires something different, please provide more detail so we can discuss. In the worst case scenario you can call back into Edge from Node JS, but this adds unnecessary latency.

thanks @Sean Davis

Part of our deployment is to use TargetServers for all our proxies along with rate limiting quotas so that we don't overload our backends.

Rather than manage URLs within the GraphQL application, the the thought was to redirect traffic into Apigee proxies so that we can leverage TargetServer + Rate Limiting.. I suspect that this isn't possible to do within JavaScript and is only available through Apigee Proxies.

I agreed on the pattern suggested above by @Sean Davis. However, on your second comment, it sounds as if you'd like to hit from GraphQL another API Proxy and apply spike arrest and rate limiting on the second proxy. Is there a compelling reason to do so? Without knowing your reasons, I wouldn't recommend it. IME the main downside with this approach is that there's no point in letting requests to go through to another proxy that will reject requests anyway. So, my recommendation is set Spike Arrest on the first API Proxy. This approach simplifies your design making easier to troubleshoot configuration down the road. And let the client handle retries and network errors.

thanks @diegozuluaga

Hi Zameer, could you provide sample proxy with graphql node js if you have any . thank you