Has anyone ever tested or know if there is any difference in performance between creating your API calls through the API connector or creating your own plugin for the API and using that?
Or any other pros and cons to consider between the two options?
I will be using this particular API in multiple apps (though different set ups for the calls as slightly different use cases) which is the main reason I am tossing up creating a plugin as it would save me some time down the line but just wanted to hear opinions from the brains trust.
I think Bubbleās API Connector is meant for insuring security. I know for me, I find using a plugin and running an API call in there is sometimes easier just because that is what I am used to but I know it is less secure. Curious to hear what others think.
I think when you use a private key for an api with the connector and mark it as such then they make sure that no one can access it. When I use an api call with a private key, I am not doing anything to secure it or keep it hidden. I tried to publish a plugin one time where I used private keys but I did not use their connector and it was denied so I assume that was the reason. Honestly I do not know much on the subject but that was my impression.
I generally opt for creating a private plugin as oppose to building the call in the API Connector.
Pros
Easier to separate calls to different platforms
Version control
Define and initialise the calls once and use them for multiple apps
Can easily add actions that might be relevant to the API calls for additional parsing required
Testing mode enables you to trial changes without actually changing the published API call
Can choose if keys are public, hidden or secret whereas API Connector only lets you choose public or private (which is the equivalent of secret I believe).
Easy to commercialise/share with the community
Cons
Harder to make quick changes (but can use testing mode which works really well)
Attempt to make the call from the browser doesnāt exist as an option
I wasnāt aware of any differences in security between the two (except obviously making calls from the browser requires everything to be exposed). Itās hard to comment on @williamtisdale and his experience but by setting a key as secret in the plugin builder, it does exactly that. Itās not shown on the frontend. If he submitted a Commercial or Open source plugin (which I wouldnāt do unless it really was for public use), then I can imagine Bubble rejecting it if his keys werenāt set to secret or hidden.
What sort of things would you need to attempt to make the call from the browser? Just to know what use case this con would apply to - Iām still learning about APIs.
Iām not sure about the security issues either. Lots of plugins for payment gateways around and Iāve never heard of any security issues cropping up around thoseā¦but perhaps as you say it was more of the set up of the plugin than an inherent security issue with plugins in general.
I think the key use case was around public APIs that rate limited requests if they all came from the same source IP (say Bubbleās server). If you have a public API like perhaps a weather API and you want to avoid getting rate limited, you might want to run the call on the browser and therefore use the users IP. This would mean that each call would be coming from a different IP, and therefore less likely to hit a rate limit.
Yeah I think so. Iāve chatted to Bubble before around plugin security and they did make some minor changes as part of my request but itās also worth pointing out that the items I raised werenāt really super clear breaches and were more around tidying up a few things from a best practice perspective.
Personally, I try to avoid plug-ins as much as I can. Almost all the time Iām developing apps for clients and I really donāt want to run in a situation where the plug-in is no longer supported and certain functionalities do not work. That doesnāt count for Plug-ins which are originally developed from Bubble.
I also think that some plug-ins are just not worth the money. Especially if you know a little of programming or to handle API requests.
On top, I run into a situation where I saw that the API documentation provides more endpoints, but the plug-in doesnāt (which makes total sense in most cases).
Therefore, I go most of the with private plug-ins which I use for my own apps or I create normal API calls.
I probably should have been a little clearer - Iām not asking about using a public plugin. I was asking for any pros/cons/things to consider between building your own private plugin for an API vs just doing it in the API connector
The main benefit to building your own plugin I thought was time saving when you know you will implement in multiple appsā¦but @juicebox shared some other pros as well
I have been working out the implementation of this particular API via the API connector at the moment as Iām familiar with that - but I will be exploring the plugin builder and creating my own when I have a bit more time to give to that
Iād opt to build my own if I need to clean up the response at all. It also makes it easy to share your calls between apps or users. Thatās for sure.
The interfaces are nearly identical. Not only that, but you can copy/paste from the API Connector to the plugin editorās API tab; so when youāre finished with your calls in the API Connector, youāre nearly done. Just right click on a call to get the copy/paste menu.
Note also that the API connector says you can āconvert your connections into plug-insā. Iām honestly not sure what that means unless itās referring to the ability to copy/paste calls.
And lastly, another advantage to building a plug-in is that you can sell it in the marketplace if you so choose.
Actually another question I have regarding this, if we create a plugin can that plugin exist in our clients app if once we hand the app over to them and itās no longer linked to our account?
No I didnāt end up making the plugin - I had planned to set up the calls in the API connector of the first app then copy in to a plugin at a later stage as Sudsy had suggested however I didnāt end up continuing with the API as the provider actually fell a bit short on promised features and I went another direction.
Re the handing over of client apps with a private plugin - from what I understand is that the app itself retains the permission for the plugin (like any public plugin) however you retain control over the plugin itself unless you also transfer the plugin, but then you wouldnāt be able to utilise it in any other client app So probably as an agency itās a good idea to have a range of private plugins as youāll be able to use them over and over without having to redo the work on the API set up.
Spot on. Our apps would be little more than static web-pages without our custom private pluginsā¦And there is such a large diversity in API specifications that I always end up having to write NodeJS server-side actions to handle requests. A fairly robust design pattern really doesnāt take much more than a dozen lines of code and provides exponentially more functionality in processing the API call responses.
Same question. Iāve noticed that API calls made through the Bubble API connector are slower in comparison to most other No-code competitors. Specifically, when using Xano as a database for Bubble, the response times are noticeably slower. I am curious if by using a custom plugin and some node hacks, we can optimize the speed of these calls. Has anyone compare both methods?
API connector will always beat ssaās used in bubble plugins since ssaās always have that 1 run to warm up. However, you can also use the api connector within plugins. And you secure keys by using context.keys[āprivate key nameā] within ssa code.
Not a con I need to worry about for my use case then 
