This is both a tip and a bold assertion: It is better plugin development practice to call external services in Server Side Actions using Bubble’s context.request() wrapper function around the Node Request Module than to use Bubble’s API call interface. I have five reasons for this claim, that revolve around the first claim:
Server side functions allow for incremental development, whereas API calls require monolithic development. To get an API Call working you basically are required to have all your inputs and outputs wired up and ready to go; which gets ugly quickly for all but the simplest interfaces. In contrast with Server Side Actions we can incrementally add inputs, outputs, and coercion logic. This provides three more benefits.
We can prune optional inputs from any submitted JSON, and coerce them much more flexibly
We can coerce and most importantly dimensionalize returned objects into flattened arrays of primitives, especially for interfaces that return key-value dictionaries.
Debugging and error trapping is far more straightforward in Action.
Increased security transparency. With Server Side Actions you are guaranteed the call is being made server to server; which is important for doing things like negotiating nonce signed tokens to access video services.
Now with all that said for Bubble to really make this work they would need to either:
Provide Serve Side Actions with the same kind of integrated automagic authentication that is in API Calls. Maybe adding some form of context.auth object.
Or perhaps much easier, add the same JavaScript and Node functionality to the API Call tab that is in the Server Side Action definition interface.
I personnaly don’t agree with you.
The only point I can agree is to handle dictionnaries issue. It’s the only way.
I consider a server side action plugin to call API only as a workaround to what you cannot do in API connector. API connector should have priority over a custom server side action call.
Nah, both are different things, to each their own
API Connector should never be able to be injected with code.
I ditched the API Connector long ago and even forgot how it works, to me, making the requests through code is much easier for the reasons you mentioned and many others more that you’re likely aware too.
Auth in server side actions isn’t that complicated once you do it a few times and have the hang of it or find good documentation to auth with the provider you’re interacting with.
It was not my goal to talk about my course, but this point that you raised in favor of the server side calls is so strong that in my plugin making course I have a full article called “Ditching the API Connector”, the experience is so much better without it!
However, the API Connector, while cumbersome for us, is super enabler for 99% of bubblers. Without it they wouldn’t make web requests at all! I started there too so I know how enabling it is.
Exactly! I’m discussing the API Call tab in the plugin developer, not the API Connector Plugin (which needs to remain as is for the community).
The query string support works as expected around optional parameters. It’s the JSON specification that really needs some improvement. At the very least they could support TypeScript type definitions (the question mark { optionalfield?: <uniontypewithundefined> } annotation anyone?) so that optional fields could be expressed fluently.
Much of the difficulty comes from JavaScript’s originally dynamically typed nature, where you are left with many not quite overlapping ways of specifying various levels of unknown, unavailable, etc… i.e. empty string versus undefined, versus null, versus falsy, versus NaN, etc… And as such every web API has different standards around acceptability of missing fields.
Agree with everything said here… I’ve been transitioning over to making context.request() calls recently as my use cases get more far fetched
I’m now trying to figure out the inverse of this… @vini_brito@Jici@aaronsheldon your thoughts appreciated in advance! I.e. how I can setup an inbound endpoint for maximum flexibility.
Apologies if I have missed a glaringly easy answer to this.
What I need to do is receive an inbound POST call to a fixed endpoint address, but the parameters are going to vary quite a lot. I will process this through Server Side functions and make sense of the payload, I just need the endpoint to be open-minded enough to receive whatever it gets sent and to pass it onto my functions.
One route, though not great, would be to necessitate the payload arriving as a stringified payload within a text parameter that I could parse downstream. Ideally I would just receive the payload as JSON though.
Bubble allows you to expose both Data and Workflow APIs from your app, see here and here. While I am not privy to Bubble’s security architecture I have been doing development long enough to know that trying to re-create the same functionality of ingesting inbound traffic in the Plugin Developer could be both a security and capacity nightmare. However some of this could be addressed if Bubble would please, please, please add a Data Types tab to the plugin developer.
Thanks for reply.
The intention is to build off of Bubble’s standard in-bound endpoint architecture, though try and find a way to bypass concretely specifying the JSON structure and handle it myself - much as your describe with your response handling to outbound calls above.
There likely isn’t a hack for what I’m trying to do.
I will either: a) receive the payload as stringified JSON via a text parameter, or b) receive standardised objects via an array and unpack them.
A data tab would be great. I spend a lot of time creating fake API structures in order that I can use them throughout my apps.
I’ve been toying with a gnarly work around for custom API endpoints in Bubble. The gist of it is:
Set up a custom NodeJS REST endpoint in AWS Lambda. This can actually be driven by Bubble using Amazon’s AWS Lambda API.
When the AWS Lambda API receives data the service then calls a “Delivered” endpoint in Bubble.
The “Delivered” endpoint then turns around and retrieves the delivered data from the AWS Lambda.
There is a whole bunch of stuff around authentication, logging, and cleaning out delivery queues that I have left out. But any seasoned developer would be able to figure that out.
