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

3 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!

5

For what it’s worth, I’m seconding this suggestion. It’s so fundamental that it’s going to decide (in the next month or two) whether or not I stay with Softr after making a large investment in time and treasure into this platform. I can’t ask clients to reload a page manually; it’s just embarrassing, and makes it looks like I’m behind the curve, which is bad for my business. Thanks -

6

This is why I’ve avoided anything advanced with Softr. So I keep workflows very simple, even avoiding 3rd party integrators as much as possible. I would like to do something advanced, but I’ve run into too many performance issues over the years like this one.

It appears Softr should have started with their own database in the first place, or at least a lot sooner. IMO, connecting to so many databases has overcomplicated Softr’s roadmap and quality assurance, to the point where I’ve felt like I’m paying to perform Softr’s quality control. Let’s hope Softr’s Tables will be powerful enough to build useful apps while avoiding these kinds of usability issues I’ve been dealing with since 21’.

7

Can’t say that I am a big proponent of Softr database. Modularity is a best practice. Putting data into the same nocode platform that manages the front-end is not a smart choice, in my opinion. It locks your data in. Also, it can’t possibly be scalable, if you needed to manage millions of records.

Agree that Softr’s strategy to pursue every data source under the sun is not the best. There are too many of them and it sucks dev resources out of Softr’s team just to keep up.

I think Softr should have perfected the generic API data source with a true CRUD. I think if they had done so, it would allow the users to connect to practically any data source ourselves using the data source’s APIs. And if they did it right, it would incidentally solve the request/response signaling issue that we are bashing in this thread.

Softr came up with an API data source. I was so excited about it. But it’s been sitting in Beta for some time now. It’s clunky and limited and it doesn’t look to be improving. Only Softr can tell us if this is by choice, as they are working on some functionality that may supersede this API data source, at least in its current form.

8

In theory, modularity is the safe bet for the reasons you mentioned, but in practice, with Softr’s performance issues, I foresee Softr’s tables vs datasources as a trade off for no-coders. I imagine performance and reliability will be significantly improved using their tables, but power will be very weak compared to external datasources. It’s still a tough call to determine which data option will be best moving forward, given the fair points you made, Softr’s datasource performance issues thus far, and the inevitable quality issues that will have to be dealt with regardless of which option we choose.

9

Hi y’all,

A couple of quick notes:

With our updated data synchronizer rolling out soon for all data sources (already live for some), you’ll be able to refresh data in the background—no need to reload the page. This includes Softr Databases, which will also gain additional powerful features.

We designed Softr Databases to scale—even to millions of records. There’s currently no reason to believe they can’t handle large datasets, but if you’re seeing anything that suggests otherwise, please let us know so we can investigate.

I encourage you to give Softr Databases a try now—and again in a few months once it’s out of beta—before assuming it won’t be powerful enough.

3 Likes