Block refreshes after 3rd party tool API calls

Feature Requests
1

Hello Community.

I have been using Softr for years now and like most of you who are in the same shoes, have seen the good, the bad and the ugly…

Softr has a number of strengths and a number of drawbacks, like any other tool in this category.

For the drawbacks, many have a work-around. Some require a JS code injection here and there and Softr support is wonderful when it comes to helping out with those little code snippets.

Last year Softr introduced a “Call API” action. This was great, but it had a fundamental flaw. That is, when one utilizes the “Call API” action to call a third party tool like Make or n8n, for the purpose of making complicated data manipulations beyond what the native block’s CRUD actions offer, the changed data DOES NOT get reflected in the block’s data upon the automation’s completion. To see the changed data the user needs to either manually refresh the app’s page or a JS script needs to handle an automatic delayed page or block refresh.

Neither one of these two work-arounds are perfect. The first one is just bad. No serious modern application on the web would ever require a user to manually refresh the page after clicking a button that is supposed to change some data. The second work-around is not great either. A delay is usually an arbitrary number of seconds, estimating how long the backend automation may take before succeeding. But what if it takes longer than expected? What if it needs to do some delayed retries? There is just no guarantee that by the time the delayed refresh executes, the backend automation will have completed. Besides, that’s another thing that modern serious web apps don’t do - de-coupled delayed refreshes of pages after an on-page action by the user. So, both of these work-arounds violate the modern web app design and user experience.

The problem is that there is no true “signaling” back from the 3rd party API call response back to Softr, which other tools like Bubble or WeWeb might use. The API response is not waited for, not interpreted and not binded to the block’s data items.

I realize that the response’s binding to the block’s data items might be a bit too complex for a tool like Softr, but at least awaiting the API’s response would be great, ensuring that the page refreshes ONLY AFTER the backend operation has completed.

I use Make, but I know that both Make and n8n provide webhook response and structured output modules that can be the last modules in the workflow that can provide “signaling” back to the calling process. So, from Softr’s perspective, all it needs to do is await the response from those modules before completing the block’s action operation.

I honestly don’t know how many of Softr’s users have been struggling with this flaw. I certainly consider it “fundamental”. I’d like to think that it must be a considerable hindrance to those building anything beyond the most simple applications.

I hope this is something that Softr will address soon in their platform updates.

Thanks

2 Likes
2

Thanks for your years of support @bbelo !

I understand your frustration, and can say that we would all like this to be handled better. It’s just a difficult problem to solve for, as you’ve shown in your post above.

I do have good news though - we’re in the middle of migrating all of our datasources to a new caching method that will enable auto refreshes of data once it’s been updated in the database (without having to refresh your page).

This way, once you hit an API, and it changes data in the database, it will be refreshed on the page once complete. However, there is no telling how long this will take as we’re relying on external APIs / automations, so could still create some delay (5 - 20 seconds?)

Our workflows product will also solve for this with more elegant solutions.

So, we understand where you’re coming from, and are working towards a good solution to this problem, but it’s a difficult one and requires substantial infrastructure upgrades to solve, which we are in the process of doing, and hope you can benefit from these updates in the near future.

At the moment, it looks like Xano will be updated to this data source method around May / June, and other data sources have either already been updated or are a work in progress.

And workflows is expected around June / July as well. So help is on its way!

3

Great, JJ.

Sounds like Softr is attacking this thing on multiple fronts and it sounds like a resolution or maybe even multiple resolutions might be, indeed, on the way.

To be honest, I made this post just to make sure this issue “resonates” with the Softr team. Sounds like it does and that’s half the battle :slight_smile:

Will patiently await these improvements.

Thanks!

1 Like
4

Glad to hear, my friend. We’re certainly aware and are working towards a better solution!