Updating plugin editor to new node version

[MindForApps]

@redvivi

So, it means that a fully-tested node14-upgraded-plugin with its test app (on test cluster) may fail on production applications.
Hence, all manually-upgraded the plugins to node-14 by plugin authors MUST still be backward with node-12.

Do you confirm?

Quite right. We have exactly the same situation. In the test version, everything works fine, but after publishing, users get an error.

@redvivi

I also note a performance degradation for node-14 upgraded plugins on Server Side Actions.
The cold start is around 40 sec, which is more than three times what was on node-12.

Exactly. And even our users who use our plugins are already complaining about it.

[redvivi]

@MindForApps

Quite right. We have exactly the same situation. In the test version, everything works fine, but after publishing, users get an error.

If I may quote one of my user:

ᴺᴱᵂ ᴾᴸᵁᴳᴵᴺ AWS S3 Dropzone & SQS Utilities (MultiUploader, Folder Support, No Filesize Limit & Automated AWS Environment Setup!)

That seemed to work. I let loose a number of expletives that I won’t share here. Thanks for the fix.

Let’s all remember we have many businesses on the line.

[MindForApps]

@redvivi

If I may quote one of my user:

Yes, I also had to downgrade the package yesterday to make the plugin work.

[troy.roberge]

@sam.morgan @josh

Seems like you guys have some semi-breaking issues here.

Comments are required please.

[grace.hong]

Hey everyone - Thanks for bringing up these issues! We’re investigating them right now. In the meantime, please do submit bug reports here, so we can see if we can reproduce these errors.

[grace.hong]

Hey all, we just pushed a fix! Please publish a new plugin version, so it has the correct code, which uses node 14. Our apologies for the inconvenience!

[redvivi]

Thanks @grace.hong , will be testing out.

What about the performance?

@MindForApps

@redvivi

I also note a performance degradation for node-14 upgraded plugins on Server Side Actions.
The cold start is around 40 sec, which is more than three times what was on node-12.

Exactly. And even our users who use our plugins are already complaining about it.

[grace.hong]

Hi @redvivi, we’d be happy to investigate this. Would you be able to send in a bug report highlighting what you’re facing? We need at least one concrete example to investigate. Really appreciate it!

[redvivi]

@MindForApps : I don’t have any remaining plugin running on node-12 engine.
Do you still have a case to demonstrate node-12 vs. node-14 perf for @grace.hong ?

@grace.hong

Hi @redvivi, we’d be happy to investigate this. Would you be able to send in a bug report highlighting what you’re facing? We need at least one concrete example to investigate. Really appreciate it!

[MindForApps]

@redvivi

Do you still have a case to demonstrate node-12 vs. node-14

Ha! No, I already switched everything to 14 too.
But visually it seems to be better with performance (or maybe I’m fooling myself?)

[JohnMark]

Hello @grace.hong

Yesterday while doing performance tests on a plugin that calls a routine to start the Amazon server was taking more than 40 seconds. Today it’s still between 20 and 30 seconds. But once executed by Bubble, I can restart the request which will be processed in 2 seconds by Bubble. If I wait between 2 and 5 minutes, it still takes 20 to 30 seconds to start. I think I understood that Bubble slows down the plugins at startup, and then acts normally. I would like you to clarify this situation before making a report.

I have another example with a WAIT plugin. It pauses between 100 ms and 25 seconds. For the first start, it always takes 10-12 seconds. Then it respects the time. So it’s normally easy to accomplish.

[exception-rambler]

Based on what others are reporting @grace.hong we’re holding off of our migration. It would be great if you could post an update here once the team have had a chance to check out the behaviours described above. Thank you!

[keith]

For my Floppy plugin (which has 1 SSA at the moment), after migrating the plugin to Node 14 on Nov 2 (but pushed an update again just now), I’m seeing cold start times around 10 seconds for my SSA (which seems slightly worse than in the past, but perhaps I’m mistaken?) in both test mode and apps using the production version.

At any rate, I’m not seeing crazy 40 second cold start times. Though it feels like there might be room for improvement here.

ALSO, FWIW, I did just check out my “Return 5” open source plugin (which just returns a number), which I have not attempted to migrate to Node 14 (I note that I do not see the option to do so today – has that been removed temporarily?) – it’s still on Node 12 – and when tested it shows cold start times around 5 seconds. So, yeah, I think there’s some issue with cold start times and Bubble’s Node 14.

I have a demo page that tests both actions (linked below), @grace.hong . You can open the console to see Debug Buddy report roundtrip time. I was just playing with this, so one might not see cold starts right now, but perhaps this would be helpful to you:

https://list-shifter-demo.bubbleapps.io/version-test/list-math-ssa-test?debug_mode=true

Worth noting that I’ve not experienced @aaronsheldon’s issues with packages (reported elsewhere) as I haven’t attempted migration of any SSA with dependencies just yet.

[grace.hong]

Hey all - Thanks so much for providing additional detail. Our engineers have taken a look at the upgrade code, and as of now, it should be safe for you to migrate to node 14 since any outstanding bugs won’t affect node 14 any differently from node 12.

We believe everything is fixed on our end, and that our serverside plugin code is sufficiently agnostic to node version that the only reason there would be a difference in performance between node 12 and node 14 is if there were an AWS bug. In theory, it is possible that there may have been a performance regression around creating plugins (although we don’t believe there is one currently), but such a regression would affect both node 12 and node 14.

For those who may believe they’re experiencing performance regressions, please do submit a bug report, so our engineers can use those examples to investigate!

[aaronsheldon]

• “latest” of PDFJS still does not build. Currently have it pinned at “^2.16.105”, which does build.
• “latest” of the AWS v3 SDK references NodeJS 14 language constructs like nullable field referencing operator “?.” and fails in runtime on the obvious syntax error. Currently experimenting with pinning at “~3.200.0”

The runtime failure of the AWS v3 SDK is particularly shocking considering our actions consist of a half a dozen lines to make a single asynchronous launching call to AWS Lambda. Something this small should just work. We are basically just passing a whisper of a message to AWS Lambda.

[redvivi]

@redvivi

Node 14 will be EOL in 6 months…Node.js | endoflife.date

Perhaps you would rather upgrade to Node 16, giving more headroom ?

@grace.hong

Thanks for reaching out! We’re aware of the upcoming Node 16 migration, and we will definitely be offering a Node 16 upgrade path in the following months with a longer delay than what’s provided here. Given the timelines involved, we can’t offer Node 16 right away. Rather, we have decided to focus on upgrading to Node 14 since that’s the most low-lift solution to ensure our users’ apps remain unaffected by the deadline.

Coming back to my initial reply @grace.hong, you might want to reconsider the ample headroom I suggested…

[grace.hong]

@aaronsheldon Would you be able to submit a bug report, so we can investigate your particular case? We built a test app and plugin using those packages on the latest version, and the build/run succeeded. The bug report can help us understand what might be happening with your app.

@redvivi Thank you for the reminder - yes, we’re planning for this migration and do want to give users headroom. I’ll be sure to share updates when we have that migration ready.

[jonah.deleseleuc]

@aaronsheldon

Currently experimenting with pinning at “~3.200.0

Hey Aaron,

You’re right - I’ve found that pinning my server side actions that are using node to a specific version of a package to be 100% recommended. Some packages nowadays are moving away from the require syntax. If a future update uses the import syntax, your code will break without you knowing

The best example I know about is the popular package Node Fetch, which only works on ver. 2.0.0 because the latest requires import

Of course this wouldn’t matter if latest meant the latest package at the time your plugin was published, but that isn’t written anywhere so I doubt it!

[aaronsheldon]

The move to ES6 syntax is going to hurt…

[JohnMark]

@grace.hong

Suggestion. You should identify all potentially risky Plugins with a red marker in the Plugins section to make non-developers and developers aware. I use an incredible number of them, and I don’t see myself contacting them all. Also, I would like to know that my plugins have received Node 14 or 16 certification for the future with a green marker.