What are the best practices in choosing between XML based Proxies vs Node Embedded proxies

Google Cloud Apigee
1

We currently have have a total of 25 proxies (or so) that our two teams currently maintain. The list is growing fairly steadily, and we are about to open the floodgates. Over the next few of months we will be on-boarding several new teams to do their own Proxy development work. Part of on-boarding preparation is putting together reference templates for any new proxies that would be used to get the new teams operating quickly.

Moving forward, most of the services we will be proxying in apigee are AWS based services / endpoints. Most of the Applications are Node based, but we will likely have some other technologies mixed (Java, etc). The Apigee proxies needed would be simple wrappers to those services for the most part, taking advantage of existing Policies (Oauth, Threat Protection, etc).

When we first started to talk with Apigee, AWS wasn’t playing as big of a part as it is starting to now, and we were looking at Apigee Edge almost as an application server in addition to being a proxy.. Allot of complex aggregating and transforming logic was built into our older proxies, and we started to embed Node.js for the more complex of them. This brought up alot of design discussion with our architects about embedding Node in all of our Apigee proxies - even for the simple wrappers.

In December, we had a “Dojo” with apigee (@srichardson) - a week long training in integrating swagger and node into an Apigee proxy. I seem to remember the person that was presenting said that we needed to be careful when implementing Node.js in proxies, that it required additional resources, and that for heavily hit applications it could cause degradation to the overall performance (not sure if he meant just the Proxy in question, or the organization as a whole - we only have 2 MP’s).

I’m not sure anyone remembered that initial warning, or maybe i just misunderstood, and since then we have continued talking about having all of our proxies be node based (i.e. having an embedded node wrapper to our targets)…

Questions:

Would we see service degradation if all of our proxies are converted to have their own embedded Node.js apps, verses all of our proxies remaining solely XML policies? (Especially considering the potential of many new proxys being created over the next few months as teams start to ramp up - and all of them being directed to implement with a Node.JS Embedded approach)…

What would be your suggestion as to weather we should stay with an XML only approach versus fully converting over to a embedded Node approach for all new and existing proxies?

@dallen

1 Like
2

Just to get the conversation going, here a few points I’d consider:

  • not sure why, but I don’t see any advantage in having a node wrapper going to the target

  • just adding node to a proxy before hitting a target url will add extra time and close to zero benefits unless you are leveraging some other pre existing code or doing orchestration with other services to justify the presence of node

  • node is very powerful if you have scenarios where you are doing mashups/orchestration where you benefit from async responses from the multiple services

  • a policy/xml based proxy relies on tested/hardened code that are a lot more likely to be bug free than freshly built node.js code

  • any code written is bound to having bugs and javascript and node are no exception

  • the more lines of code you write, the bigger the probability of introducing bugs at code creation or later doing maintenance

I love node and it has its place but for an api proxy, 95+% of the cases can be addressed with policies (and maybe a few spot tasks in js), making me pick node for the needed cases only.

1 Like