Terms of service questions around building third party tools

[boston85719]

@boston85719

Simple example for you Rando, is the logs API. Already we know Bubble has requested buildprint and likely the other log services hitting the API on a schedule loop to attempt to provide a ‘log alert’ offering from their product was something Bubble was not happy about and why they asked them not to hit that API as frequently. Publicly it seemed to be due to a strain on resources, but I personally could interpret it as also against Bubble business interests

@georgecollier

That’s not the reason at all. It’s just that Bubble’s moving their logs to a new backend (which everyone benefits from), and during that cutover, they need some rate limits to ensure stability - Buildprint is accounting for a significant proportion of requests to Bubble’s logs endpoint.

@Zeroic

Correct - we run a job every 5 mins that fetches the updated logs.

As for retention, yes, this extends further that the plan-specific limited period which Bubble offers (and unlike other similar tools that exist atm). We’ve currently set a TTL for 90 days in our OLAP DB, which we’ll be extending later depending on the demand

@georgecollier

PSA: We now account for a significant amount of Bubble logs requests so are throttling requests whilst they’re doing some planned backend work (that will improve logs for everyone, whether you use Buildprint or not). If you see log sync fall behind, that’s why.

@georgecollier if you read into what I said, the part where “I personally could interpret…” that is significant to the meaning of the statement, and why I am asking Bubble for clarification. It wasn’t meant to imply that it is the true reason, it was meant to significantly improve the understanding of why I would like clarification from Bubble about what might be seen by Bubble as against their business interests and therefore be something that would result in Bubble saying a service is going against their fair usage.

All I had to go on was what was publicly stated, which I summarized as ‘stop hitting it on a scheduled loop’…I had not gone back to see the exact quote from you saying ‘rate limited’ for a cutover period. I must have confused my expectations of another log provider looping every 5 minutes being reason for Bubble to request ‘rate limits’.

@georgecollier

So, the idea that they asked us to rate limit because our feature enabled stuff that’s not possible natively or it disincentivises users upgrading just isn’t true

Again, read it clearly, says “I personally could interpret” which doesn’t mean I am stating that it was the reason…it was meant to highlight why I am asking Bubble for clarification about what goes against fair usage and is potentially seen as against their business interests.

@georgecollier

If Bubble asked us to stop something, would we? For sure. For example, we used to offer backfill on logs but stopped that because it led to too many requests.

Maybe that is where some confusion came from, and I glanced over the concept of backfill logs.

@georgecollier

This is also not how log alerts work, we don’t poll for conditions that are met from Bubble, that would be very inefficient.

I guess you might be doing it differently than @Zeroic and Zerotrace…but by the way, I didn’t imply there is polling for conditions, just an idea of hitting the api every 5 minutes to get updates to logs, the way explained by @Zeroic and how Zerotrace does it.

@georgecollier

But the reality is that Bubble benefits from good community integrations as long as they respect the platform systems, don’t affect end users, and just generally positively contribute to the ecosystem.

Yes, that is why it would be great to know what kind of integrations or how to integrate that do not go against the fair usage policy statements I highlighted that for me personally, cause me confusion about how to provide such integrations.