Alpha invite for Plugin developers: Bubble Plugin API Version 4

[henry.dowling]

Hi all,

We are excited to release a public Alpha for the Bubble Plugin API Version 4 today.

Bubble Plugin API Version 4 affects server-side actions only. Because AWS Lambda functions, which we use to run server-side actions, will likely end support for Node 14 this year and migrate to Node 16, plugins that use server-side actions will soon be required to switch to Bubble plugin API version 4. We are running an Alpha to ensure that version 4 is easy to upgrade to and allows authors to make full use of the benefits that Node 16 provides.

We invite you to try it out by clicking on the “Try out the Alpha” banner in the “Shared” tab of your plugin editor and then switching your version in the Bubble Plugin API Version dropdown to “v4-alpha”.

Check out the documentation here!

FAQs:

• How do I join the Alpha?
  • Click on the “Try out the Alpha” banner in the “Shared” tab of your plugin editor and then switch your version in the Bubble Plugin API Version dropdown to “v4-alpha”.
• Why are we releasing an Alpha?
  • v4 of the plugin node 16 API will change the syntax of server-side actions in a non-backwards-compatible way.
  • We would like to get feedback from plugin authors to ensure that our API design makes sense to plugin authors, and that the update is easy.
• What does “Alpha” mean, exactly?
  • You will not be allowed to publish plugins that use version 4 Alpha of the plugin API.
  • We might expect to make breaking changes to the Alpha.
• What is the timeline for the node 16 upgrade process?
  • We will announce a full timeline for the upgrade process after the Alpha is complete and feedback is incorporated.
  • The Alpha will run from now until early June. In early June, we will release the full v4 version, which may include some changes relative to the Alpha based on the feedback we receive (for example, we may add utility functions, or change some function names if something is confusing or unnecessarily clunky).

Please leave feedback on the Alpha here, or below in the comments to this forum post.

[lizzie]

Server side, rip for those using plugins to cut down on WFUs

[Bubbleboy]

SO let me get this right… Bubble announces all of the changes etc… the entire community comes out in a rash and asks valid questions seeking clarity… NONE is coming from anyone at Bubble and Now you pop up releasing an Alpha and which is like “can you help us test this stuff and iron out the bugs” LOL good luck with that

[doug.burden]

You’re going to have to provide us with what you’ve changed or reiterate it as we’ll need something to go off of to provide feedback other than saying you’re upgrading to another outdated version of node.

[dorilama]

@doug.burden

You’re going to have to provide us with what you’ve changed

[dorilama]

from a quick look the examples could use proper formatting and a clear separation between old API and new API.
For example “context.request: Current plugin API” has an example code with inside also the code for the new API.

[doug.burden]

where do you find this?

[dorilama]

First link in the annpuncement post:
https://manual.bubble.io/pre-release/alpha-bubble-plugin-api

[aaronsheldon]

I’m glad to see Bubble making the transition to supporting native asynchronous processing. After carefully reviewing the documentation there are two obscure, but important, points I want to highlight for future readers:

1. The node-fetch package is declared as the global fetch. This means that even though this is only an upgrade to NodeJSv16, with respect to the fetch API this will work much like NodeJSv18 and above.
2. The Bubble functions are now declared async function(properties, context). This means you can return a promise containing a properly structured object, because promises are idempotent; a promise of a promise is just a single promise. This basically obviates the need to use context.async ever, as you can just return the terminal then in a chain of promises.

Overall, this looks to be a substantial improvement in the server-side plugin framework.

[tamsgen15]

Dear Team Bubble,
Thank you for inviting me to the public Alpha for the Bubble Plugin API Version 4.
I appreciate the opportunity to try out the new version and provide feedback.
I understand the need to switch to Node 16 and appreciate your efforts to make the transition as smooth as possible. I will be sure to try out the Alpha by following the instructions provided and will leave feedback on my experience.
Thank you again for including me in this exciting update.
Best regards,
Temesgen

[vini_brito]

I am still going to test, but… seems like now we don’t need to require fetch anymore, got top level async and can just await everything including Bubble API methods.
And by top level I mean from my point of view, or “point of context” if I may invent a new term.

And what we need to do is to change existing code to await the gets etc from Bubble API and add .v3. to object and functions names.

Sounds good, I was afraid of an earthquake in the overall paradigm, glad to see it is just some modernization of the same flow and mental model.

Something that crossed my mind… at first it seems like you can just remove the context.async!
And make the top level async the default, since it won’t make a difference if people are not using asynchronous functions since synchronous stuff will just run synchronously.

Leaving it there will just complicate things for newcomers.

Because I only use context.async if I want to return the results from an async call to the bubbler so he can use it as “Result of step X”, but you added top level async, so that will cover this use case, right?
Specifically, with top level async the server side function will wait until all the awaited async operations finish?

That is comparing with the current behavior for the server side function, which is to finish once code runs regardless of their asynchronous pending stuff and the only way to make it stay alive is to use context.async.

And maybe you can remove context.request as well, since we can just use the simpler and better fetch, because if I understood it correctly you are already requiring node-fetch or similar package for us by default.
We will already have to do the work of changing the code to await the request anyway, might as well swap for fetch.
But I understand if you leave context.v3.request there to make it feel less of a breaking change or if there is any other use case that I don’t know.

As for the unsaid things, I will still test stuff to see if anything else breaks.

[dorilama]

Just a thing to point out: the global fetch is a function that dynamically imports the private package @bubblegroup/node-fetch that is probably a fork of node-fetch, but we don’t know what it is actually (e.g. what version of node-fetch?).
It’s probably better to import directly the public node-fetch package to have control over the version used.
Personally I think it’s a bad choiche to declare a global fetch because in the next version of node there is already a global fetch that follows the standards. If you use bubble’s global fetch next year you probably will need to check that nothing breaks when aws will upgrade the node version.

[vini_brito]

Yeah we may need it to be 2.6.*.

[aaronsheldon]

You can double check this with @henry.dowling. My understanding is that the global fetch is a stopgap for the transitional upgrade to NodeJS 16. With the intention to deprecate the global in the eventual upgrade to NodeJS 18.

In the grand scheme of things the price to get Bubble finally following NodeJS upgrades had to be paid at some point. It is better we start anticipating the maintenance requirements of plugins now, rather than getting flat footed in the future. The ECMAScript standards have settled down quite a bit in the last couple of years. So we can expect that once Bubble catches up to NodeJS 18 the interpreter environment of server-side plugins will become very predictable.

[dorilama]

why should they introduce a global now and deprecate it next year?
There is actually no need to introduce a global fetch, the API upgrade is because fiber is incompatible with node >=16 and it was deprecated 2 years ago. Nothing to do with fetch.
If bubble feels the need to introduce a global private package they can name it in a way that is compatible with the next node version.
We are talking about plugins here, it’s full yes-code, we know how to import packages, even with dynamic import

[aaronsheldon]

I believe the same rules around async functions that are true of NodeJS in general will apply here. The function will cancel all execution as soon as the highest level return is issued. This means that if you want to ensure all your asynchronous code completes you will need to collect all your promises, or chain them, into your return.

This is how AWS Lambda execution works as well.

[aaronsheldon]

The reasoning is that they are deprecating the context.async and context.request functionality as well. As such, they wanted to ensure there was a comparable default alternative for plugin developers, that provided more than simply “go require the package yourself”.

[dorilama]

in the current api there is no fetch, only bubble’s request.
The next version of the api mantains the bubble’s request adapted for async.
There is no plugin that is currently using a global fetch.
Node v16 will reach end of life on 2023-09-11.
Node v18 has a global fetch that is standardised.
Bubble’s global fetch is a private package that is not known.
There is 0 need to make it global with a known reserved word.
“Go require the package yourself” is the easiest part of the job

[zelus_pudding]

Hey Henry, thanks for the post! Out of curiosity, can you speak to why the team has opted for Node 16 instead of implementing 17 or 18? I imagine you’ve internally had healthy discussion on this and I think sharing some of it would really help the community (and myself) empathize with the trade-offs you guys have to balance. Really hope you can share something. Thanks!

[zelus_pudding]

@henry.dowling , bumping my last question.