Different plugin parameters for live vs development

Does anybody know if it’s possible to have different configuration parameters for development version?
When working with API connector, I’m ponting it to my local IP but I don’t want to have to keep changing these across the board every time I want to push a new live version out

1 Like

Make two API connections in the Connector, one for development and one for live. Then everywhere you add one add the other. Put conditionals on each, add dynamic value and look for the option “Isn’t live version”. The workflow for your development version should say “Isn’t live version” is “yes”.

thanks for the suggestion!

I’ve managed to do this with a single connector where I’m using a param that gets translated to an endpoint (via an option). but the problem is having do to this for every call and every endpoint! Lots of room for errors.
I feel like even having a “base URL” type thing for APIs would solve half he issue, so that at least I don’t have to maintain this paremeter on a call-by-call basis, but sadly that’s not a thing in bubble.

I even started building my own plugin, but ran into a different issue. Plugin actions don’t allow you to definie good response types - no nesting.
And API calls configured for a custom plugin have no awareness of live vs dev. There doesn’t seem to be a way to reference parameters defined at the plugin level either.

Can you give me a few screenshots or examples of how much you need tio change the url. With a plugin you can expose as many different states as you want so instead of just returning one thing with alot of nested data, you could return as many different variables as you need and name them in a way that you know where they came from in the complex return data. Here is an example of how I determine which url to use for an API I have in one of my plugins, but note that since creating this I have realized I could just pass in a property from the “Isn’t live version” variable made available.

//Getting Version Pathname
instance.data.version = window.location.pathname.split('/')[1]

//Determining if environment is testing or production
if(instance.data.version === 'version-live' || !instance.data.version.includes('version')){
    instance.data.testing = false
    instance.data.version = ""
} else {
    instance.data.testing = true
}

//Used to ensure the console logs will not show in production version
instance.data.consoleLog = function(arg){
    if(instance.data.testing){
        console.log(arg)
    }
}

//Determines the api endpoint url based on version
instance.data.determineEndpoint = function(isObj, endpoint, id){
    let url;
    id === undefined ? id = '' : id = `/${id}`
    if(isObj){
        url = `https://example.com${instance.data.version}/api/1.1/obj/${endpoint}${id}?api_key=${context.keys.bubble_api}` 
    } else {
        url = `https://example.com${instance.data.version}/api/1.1/wf/${endpoint}?api_key=${context.keys.bubble_api}` 
    } 
    return url
}  

//Backend Workflow Use Case
const url = instance.data.determineEndpoint(false, "example_endpoint")

//Object from Database Use Case
const url = instance.data.determineEndpoint(true, "thing", "1234exampleID5678")

Thanks for providing an example.
This would only be applicable to the requests done on the client end though, because you’re trying to determine the version from the pathname component, correct?

This the setup that I currently have.

I then have the following option set setup:
image

An example of one of the options is as follows:

And finally, when I’m making the call from the page. I pass urlEndpoint param by converting Isn't live version to one of the option sets
image
image

As I have mentioned before. This makes setting up the endpoints and then calling them more tideous than needs to be. And the more things I have to maintain the more room there is for effing something up.

@aleksei check out my solution here; How to handle development/staging APIs with Bubble?

1 Like

Posting this as a separate reply to keep things cleaner.

I worked out that I can see individual API endpoints’ params marked as Secret in the plugin configuration, which is definitely a step in the right direction, but unfortunately those aren’t shared between the calls, so I would have to duplicate the same value for each endpoint
Setup


Configuration
image

If I could somehow reference the shared server-endpoint parameter that would be great.

Alternatively I’ve tried setting up these calls as Actions of the plugin, but the problem I run into there is being unable to define complex return types as I’m limited to the following options
image

@juicebox I saw this after I already played around with different paremeter configurations.
This would have worked perfectly if you could define a shared prefix for all calls of a given API, but right now, simply using the same name, gives you an input box for each call in the plugin configuration. Check out my previous post

1 Like

@aleksei no worries - the solution you’ve landed on is about as simple as you’ll find with current functionality.

thanks, @juicebox
I was worried you’d say that, though.
Is there something like a wishlist or feature suggestion page that I can pop something in?
I think having the ability to have a common URL similar to shared headers and parameters for APIs would go a long way

1 Like

You can try here; https://bubble.io/ideaboard

1 Like

Will do!
Thank you!