Is there a way to return a response without aborting the workflow?
I am connecting Bubble with Xano and using Xano for long workflows (some take hours to complete).
The problem is that Bubble expects a response within a few minutes of making the call to Xano or it will timeout. So I was thinking I could send a "workflow initiated" response to Bubble as soon as the call to Xano is made (to avoid Bubble's timeout) and then send the actual response of the workflow as a POST to one of my Bubble app's endpoint.
Is there a way that I can send this instant "workflow initiated" response without terminating the workflow in Xano?
The crux is that Xano endpoints do not support streaming output, in which an inital payload is returned before sending more data. It will only reply to bubble once.
If you want immediate, asynchronous invocation, I recommend using a second endpoint. Bubble calls endpoint A. ENdpoint A calls endpoint B and returns without waiting for it to reply. Endpoint B calls a webhook on Bubble notifying it that the job is done.
If a task get's hours to complete I would suggest to do it in background tasks and then send the results to frontend via regular endpoint.
Building on @Pawel Magdanski's idea, you can have bubble fire a request into xano that xano adds to a queue of tasks it will manage via background tasks. This API-to-task workflow is relatively common and straightforward. The API adds the info to a table, and then the background task is running every x minutes or what have you to check the table for jobs it should do.
Thanks for replying! @Pawel Magdanski @Ray Deck
The feature I've built is the following: A user of my Bubble app clicks a button, Bubble calls Xano, Xano calls some external databases and process some data (this may take hours depending on the amount of data), Xano calls Bubble returning the resulting data.
This will not be run automatically at a certain time nor be repeated at a certain time, just when the user clicks the button in my Bubble app. It also requieres some strings as input (according to Xano's docs, background tasks don't take inputs).
Taking this into account, would it be better to run it as a background task instead of regular api function stack? Why?
@Ray Deck that worked for me thanks! My only concern now is that Xano timeout my workflows, since they are long.
I could be running multiple of this long workflows simultaneously (one for each user that clicks the button in Bubble), do you think I can get problems in Xano because of lots of this long workflows running simultaneously as regular api workflows (not backend tasks)?
Yes that can cause a problem depending on how many simultaneous processes you have going, and how intensive they are. In those cases moving to a batch process to queue and sequence the requests - along the lines of what we discussed with @Pawel Magdanski in the previous segment - will address that crowding at the price of losing a bit of responsiveness (because the second process will have to wait in line or for the next task invocation) and adding a bit of complexity for setting up this time bridge.
What limits the amount of processes running simultaneously in Xano? Is it something like "cpu usage" or "capacity". Is there a dashboard or somewhere where I can see how much of that "capacity" am I using?
Taking into account that my Xano workflows requiere some string inputs that come from Bubble and according to Xano's docs, background tasks don't take inputs, then I'd have to build that queue system without using any background tasks. In fact, I wouldn't use background tasks at all, right?
So what I'd have to do is queue the calls to the regular Xano api endpoint that does the intensive workflows so that I don't surpass the "cpu or capacity usage limitations"? Please let me know if I'm not understanding correctly. Thanks @Ray Deck !
What I would do - and have done - in this situation is implement a queuing system. I have the endpoint write to a database table and then return. A background task that runs at some frequent period polls the database table for information in a "not yet processed" state. Then it processes that data and updates the table record to "processed".
So that's how you bridge the inputs from your endpoint to the background task over time. No need to throttle the endpoint.
So how can I know when the background task is running too frequently and therefore throttling the endpoint?
Is there somewhere where I can see/measure this "endpoint available capacity" usage? @Ray Deck
You can see the number of API requests run in a time period on your workspace, and the instance view will show windowed average CPU utilization on the machine.
But memory is more often constraining than CPU for parallel processes with high i/o or network wait. And Xano doesn't have great observability on that front. So AFAIK you will be fiddling a bit in the dark until that changes.
Thanks for all the helpful insights @Ray Deck ! One last question, where can I access this instance view to see the average CPU utilization? I can't find that
Go up to your instance in your paid plan - its where you select the workspace you want to be in. There you will see a stacked line chart of your CPU utilization broken down by used by the web service and the database. It's not very complete, but a start!
- 2.1K All Categories
- 43 📣 Announcements
- 32 🦾 Releases
- 30 👋 Welcome
- 552 🤷 Help! I'm a Noob
- 39 📱 No-Code Front-Ends
- 419 🌐 Working with APIs
- 278 🔢 Transforming data
- 100 🔌 Connect Xano to ...
- 13 🧑💻 Find an Expert
- 239 ❓Other questions
- 9 🔐 Security
- 13 ✂️ Snippets
- 16 🏆 Showcase
- 3 🗣️ Xano Chatter
- 49 📺 Video Tutorials
- 156 🙏 Request a feature
- 156 🐞 Report a Bug
- 17 🚀 Templates & Extensions
- 💬 Feedback