I’ll use count<1 instead of count is 0 but won’t go out of my way to prioritize WU at the expense of anything else. In that case I was just wondering if “is not empty” would be better or worse than a count.
Wait what do you use then if you don’t use custom states or vars?
You can easily dynamically set their data source!
Yeah, I also think underscores in page URLs are generally just whack and don’t look good.
Yes, and reusable elements just feel like ‘proper nouns’.
Workflow name (internal) ≠ endpoint ID (external)
Maybe - but modifying that feature in future takes longer too.
Not at all. The best way is the one that solves the problems of the client in a maintainable, scaleable manner while acknowleding their business interests. So, I’m never going to spend an extra half an hour to implement a WU saving measure on a feature which will only ever consume a couple thousand WU a month, because my client would rather spend their money on doing stuff which actually makes them money! In addition, I’ll build it in the way which makes it easy to change in future, so that if it deserves extra optimisation in future at the cost of a little bit of maintainability, that’s an easy thing to do!
And yes! It is okay to disagree with stuff because as I outlined at the start, this isn’t and doesn’t claim to be the only right way to build an app.
Currently, there are very few places that actually teach a system or general approach to building apps. I feel like different developers have different build personalities.
Ours is obviously very distinct, and yours will be different from mine. I need some kind of Buzzfeed quiz to determine what kind of Bubble developer you are. Maybe I’ll put it in Buildprint 
Well APIs are literally the only way proprietary systems allow other systems to communicate.
As for me, my requirements are a tad more complex than writing to external databases.
Oh, I think you read it wrong…it is not saying the approach for saving workload units resulted in a task that used to take only 20 minutes then requiring 2 hours…It is the opposite. The approach that enables the workload unit savings enables me to do something that in the past took me 2 hours, to now only take 20 minutes.
So, in the future, needing to modify that feature will take less time, not longer, and I’m not really sure why you claim it to be longer as I don’t think you know which process it is of mine that I’m talking about.
Well no, you shouldn’t because for that singular feature the couple of thousand workload units don’t really cost anything, but when the approach to build with workload unit savings in mind is not saving just a couple of thousand but instead millions because the clients app scaled to have needs of fetching data in the millions of workload units, then spending $50-$75 on dev time to save $1000+ a year, it is in the client’s interest to do so. I mean, it is just like everything else in terms of there being multiple ways to do something in Bubble and sometimes considering the use case for the feature results in a good decision on how to build it out and why.
Yeah, for sure, like having an app that because of the savings of workload units, being directly correlated to performance improvements, can for some apps equate to a very large percentage of their advertising dollars being used to convert sales as a faster loading app will result in more sales.
That would be funny.
Are you still going to put workload unit optimization stuff into Buildprint?
Yessir
Solid strategy, sweat about the small stuff, don’t fret about the big things.
I never said I don’t use them. The quote you used clearly read “I personally do not use custom states much in apps”.
On a side note, if you look through past forum posts on this subject of hidden data sources (ie: var), I’ve been a big proponent of them for a very long time, and became more vocal around usage of adding to a floating group since the flexbox engine was rolled out, so in this thread, my words should not be misconstrued in any way.
My point in the thread about use of hidden data sources is more about their original intentions and when/why to use them, which I believe using them to hold onto filtered selections is not appropriate, especially when the only advantage is ‘dynamic loading’ which for the most part when doing a filter operation, there is nothing to load originally as the filters were not selected (and as per use of URL parameters or URL paths for proper way to store filtered choices for search results on a search page), and we can always just load the custom state dynamically through a ‘page is loaded’ workflow event when those ‘selected filters’ maybe do have some past selections stored that need to be loaded immediately.
My strategy is more about using the tool in my toolbelt that is fit for purpose. I’ve never once said I do not use all the tools in my toolbelt.
Trust me, there’s no sweat. You’ve put more effort into each of your posts in this topic than I have in thinking about how to save WU.
True if they come at the cost of the user experience, security, or anything else. Otherwise, no. I will make/update a “counter” on Current user instead of constantly repeating searches, and I will use satellite data types for heavy pieces of data.
I should build a small plugin to do this, but I’ve been too lazy to worry about it.
Is there a plugin you had in mind?
The point of dynamic loading isn’t what you’re saying. It’s that you don’t have to update it after you make changes to a thing or create a new thing. As @ihsanzainal84 hinted at earlier, l actually think this can be problematic in a few cases, but also mostly advantageous.
