Performance OOTB policies vs Javascript Policies

[estebanlartigue]

This question was brought out to me and I didn't have a clear answer

is there a performance hit by using javascript policies instead of OOTB policies example AssignMessages to do things like form a new request object with verb etc etc.

some of the pros I found out on JS policy

- freedom to do everything I want when I want to.

- do important logic to setup behaviors later on.

- you dont need to know 100% how to setup an OOTB policy in order to achieve a goal.

this question is because we don't really know the stack apigee is using and if jumping to javascript logic would have a performance issue?

thanks for your response

[sidd-harth · Accepted solution]

Hi @Esteban Lartigue, I cant answer much on the performace impact issue, but let me quote Apigee docs,

On Apigee Edge, there is usually more than one way to implement specific functionality. Use out-of-the-box policies where possible, and avoid the temptation to code all of your API proxy logic in JavaScript. Even though Apigee Edge leverages compiled JavaScript to improve performance, it is unlikely that JavaScript will perform as well as Policies. JavaScript may be more difficult to maintain and debug. Reserve JavaScript for functionality that is unique to your requirements.
If performance is a concern for custom functionality, use Java where possible.

https://docs.apigee.com/api-platform/samples/cookbook/programming-api-proxies-javascript#whentouseja...

[estebanlartigue]

interesting! thanks for the comment, i still wish to understand if there is a performance hit, or is just maintainable code thing

[deboraelkin]

There will be some performance hit, since Javascript code is ran through the Rhino JavaScript engine. Policies are native Java code. For simple Javascript code, the difference should be negligible in the overall proxy execution time.

I highly recommend using native policies over Javascript code wherever possible