What is the plan/policy for upgrading node.js on Apigee Edge?

[#1]

v5.0 is out now and even before that most people had migrated to v.12 or v4.0 long ago.

Is there a plan to do more frequent updates?

[ceber]

This is not an answer to the specific question about plan (maybe @Greg Brail can chime in on that?), but hopefully this helps clarify a bit of the "why" things are as they are.

Node.js support in Edge comes from trireme (https://github.com/apigee/trireme). According to the readme there support for v4 is dependent on Rhino: https://github.com/apigee/trireme#what-version-of-nodejs-does-trireme-support.

The release notes (https://github.com/apigee/trireme/blob/master/RELEASE-NOTES.md) have more specific commentary on the issue also.

[#3]

Thanks @Carlos Eberhardt!

This might seem crazy, but is there > 0% chance of Apigee allowing node.js to get out of the jvm prison it's in? I realize they restrict api usage, but I'm willing to bet there are ways to accomplish this without the ball and chain of the jvm.

[ceber]

I am not the right person to answer that question, but I would be surprised if there wasn't a chance. Maybe @Greg Brail (again ;-)) has some input.. or perhaps @bala@apigee.com could add some perspective on roadmap.

But ... Are there specific things you're trying to do that you can't due to trireme?

If so, I think those would make fantastic community questions. Specifics like that can really help bring things to light for us.

[#5]

The first benefit would be answering the original question of staying closer to release-level with node.js. Additionally, I see tremendous benefits to staying on V8 from a capability and performance standpoint.

Ultimately, this is more of a strategy question than anything else. If node.js is going to be a first-class citizen, it cannot age for years on the platform. Many modules I use often aren't even maintaining compatibility with node < v.12.

[#6 · Accepted solution]

We don't have any plans to upgrade the current support for Trireme to a newer version. There is a lot of work that we have to do in Rhino to support the ES6 features. That doesn't mean it will never happen, but it's not something that we plan to do in the near future.

On the other hand, there is certainly a >0% chance of us supporting Node.js projects on Edge using "traditional" Node.js. That would include support for many more versions of Node.

I can't talk right now about when it might happen and what all of the limitations would be, but it's something that we're looking at very closely.

Today, since Node runs inside the message processor itself, it has easy and very low latency access to Edge-specific features like the cache and the flow variables, not to mention optimized modules for quota and OAuth.

If we move to a different model, it's likely that those things would not be supported, or possibly some of them would be supported in a different way. For instance, we might add a feature that gives access to the cache, but we would not support access to flow variables.

What do you guys think? Would such a thing be useful? What would it mean to you if you had a more compatible way to run Node apps, but one that does not give you as much control over the rest of the Edge runtime?

[#7]

This is great news! In terms of getting access to flow variables, I can envision adding appropriate flow variables to the request within proxy before handing it off to node. If that's a possibility in vision you guys have, you have my support 100%.

Not to push my luck, but if we're talking about node.js running "natively", might we also be talking about being able to do things like gyp compilation?

Thanks for taking the time to chime in. As an unabashed node.js fan, this is a really encouraging sign.

[sarthak]

@Greg Brail Thanks for the reply.

I have seen this rowboat project: https://github.com/apigee/rowboat. Is this something we are pursuing as the next version of node implementation? This does not look to be a very active project.

[#9]

rowboat was an experiment to try and see how the Trireme approach would work using Nashorn instead of Rhino. It made some progress and can run a number of Node apps, but no one (including me) is actively working on it now.

[DChiesa]

> we might add a feature that gives access to the cache, but we would not support access to flow variables.

> What do you guys think? Would such a thing be useful?

I like the idea of going to native nodejs. I would miss context variables, cache, vault.

Is there a good way to provide a limited set of context-variables in a read-only format to the the nodejs endpoint? For example, suppose I want to pass the developer ID for an oauth token to the nodejs logic. Or perhaps the Time remaining on the authenticated oauth token. Etc. That might satisfy 80% of my need.

[#11]

cc @Diego Zuluaga @Alex Koo @Vinit Mehta , you may want to check this thread.