Hello,
Does anyone know if it’s possible to make a server-side action run an API to get a URL and then open the URL for the user in their browser?
I’m new to bubble plugins and I’ve been trying to figure it out all day but I’ve got to the point where I’ve decided It’s not possible for the server-side script to do something in the user’s browser.
Asking here to see if some experts know any better before I try something else.
Thanks!
You could create an endpoint, return the url and make the call using the API connector instead of scheduling the API workflow.
Take into account that if you have to process a lot of data in the server side you will have to wait a few seconds before getting the response.
you could have the server side script return a value
And every time that value is returned it could fire a “when true “ conditional workflow.
It changes a state when it fires
That changed state (also associated with a do when true workflow) not only pops open the redirect but can also reset the state if needed
Thanks for the advice,
Similar to what’s been suggested I’m going to get it to return a value (the URL) that can be used in the next workflow step. I’ll then create a separate client-side action to open the URL.
I was hoping that I could make it as simple as possible all in one server-side action the same as the bubble stripe plugin when it creates a checkout when you get the user to pay.
I’m currently having issues with the server-side script timing out. Looking at the logs the HTTP request is running ok and returning the JSON body, but my action is just timing out. I’m quite stuck again now.
Wanna share your code?
I’m imagining there’s a sync code involved?
sure @jared.gibb
function(properties, context) {@hbee Someone else looking for Square integration. 
Have you returned the error, just to check?
If you don’t return an error or a response, it’s because the promise hasn’t resolved yet, right?
I spotted this in the documentation, wonder if this is causing my problem.
Note: When writing server-side actions, avoid using async/await syntax to wait for promises. The framework we use to to handle asynchronous code (notably used in context.async or context.request) relies on a special library called “Fibers”, which works very differently from usual promises and will cause unexpected behavior if async/await is used. Consider using the traditional Promise.then/catch syntax instead, which is supported by Fibers.
I’ll have a go at rejigging the code later to use promise instead of await.
yeah… sorry! I am doing a lot of async work with that syntax too. i use it both client and server side for ease. imo, it’s easier to work with than asyc/await codes
.then(result=>{
//work with a successful response
})
.catch(error=>{
//catch error code here
console.log(error)
})
My pattern for promise resolution:
const promise = maker(...);
const resolve = context.async(
callback => promise
.then(response => callback(null, response))
.catch(reason => callback(reason))
);
The callback in the .catch will forward the error to the server logs. In contrast, the callback in the .then deposits the value in the declared constant.
Here is another example that can be used in server-side actions with context.async
In this example we will be reading the contents of a file that we fetch using axios while keeping the file contents in the Buffer
const axios = require('axios');
const getFile = async (url) => {
try {
const response = await axios.get(url, { responseType: 'arraybuffer' });
const buffer = Buffer.from(response.data);
return buffer.toString('utf-8');
} catch (error) {
console.error('Error fetching file:', error);
throw error;
}
};
let execute = context.async(async (callback) => {
try {
let contents = await getFile('https://someFileURL.com/file.kml');
callback(null, contents);
} catch (error) {
callback(error);
}
});
let r = execute;
return r;