Why are Google API keys required?

sudsy · 2020-07-09T23:25:54.665Z

I might be missing something obvious, so hopefully someone can set me straight.

I have a simple demo app on a free plan that Bubble is preventing me from publishing because of a single issue. It wants me to enter Google Map and Geocode API keys in my app settings. However, I’m not using any Google services in the app. There are only 2 pages, and there is no Google Map element (or any other Google API code) on either.

If I’m not using any Google APIs, why do I need to add keys to my app? Does Bubble use Google services “behind the scenes” or something?

Thanks for any info or insights.

keith · 2020-07-09T23:45:42.024Z

Pretty much everything related to geographic addresses calls the Geocode API. I think this (new-ish) alert is triggered if you have any reference to a geographic address anywhere in your app.

sudsy · 2020-07-09T23:57:36.449Z

Thanks, @keith. I don’t think I have any such refs, but I’ll double check.

keith · 2020-07-10T00:39:10.057Z

Might be a question for support, @sudsy, as it’s surprising and new-to-me, too.

(Of course, it totally makes sense for Bubble to require one to use ones own keys here, this message is a lot more aggro than the older ones – and for those of us who make a lot of demo apps, it’s kinda shitty to aggressively require keys and then not obscure them when an app is in “anyone can view editor” mode. I mean, c’mon Bubble people. It’s almost like they don’t want anyone to teach anyone how to use Bubble. )

sudsy · 2020-11-09T18:49:41.777Z

sudsy:

I might be missing something obvious
[…]
I’m not using any Google services in the app.

I’ve recently been working on a (non-Google) map-related project in Bubble, and I have some insights to share on this topic. After a bit of sleuthing that was prompted by app behavior which puzzled me, I came to understand that Bubble’s “geographic address” data type is tightly integrated with Google services - geocoding and reverse geocoding, in particular.

Basically, any time such a data type is referenced - be it a field in a DB table or within a plugin via an action or custom state - Bubble fires off a network request to Google services to resolve the coordinates into an address or vice versa.

It’s actually pretty sweet that it “works its magic” behind the scenes without any knowledge required on the part of the Bubble developer; and I would imagine that it’s desirable behavior for many (most?) apps - as long as you don’t mind a data type (and thus your app) being wedded to Google.

Of course, it also means that such use of Google services does not require that an actual Bubble map element be used anywhere within the app - only the “address” data type.

It seems that to “divorce” your app from Google entirely, you’d need to store locations in some other format - perhaps a couple number fields for lat/lon, or a custom data type, or whatever.

It turns out the Bubble manual hints at this relationship without explicitly mentioning the tight integration with the “address” data type.

Anyway, just thought others might be interested.

-Steve

NigelG · 2020-11-10T07:34:44.042Z

Awesome work @sudsy

This also makes it clearer why you can’t sort an APII’s results or a Custom State on distance. It is all done on the database by “magic”.

sudsy · 2020-11-10T15:43:42.293Z

Thanks, @NigelG. To be fair, though, @keith said pretty much the same thing in his initial reply to my query - albeit much more succinctly (which is a bit out of character for keith ).

However, I did encounter a bug when attempting to publish a geo addr as an exposed state and then save it directly to the DB. That would generate a “cannot dehydrate a function” error in the browser console.

Additionally, trying to save a value from a non-exposed state context that would normally be converted into a geo addr would not work. The DB field would simply be empty. I had to put the value (in this case, a string comprised of lat/lng separated by a comma) into an input field and then save the input’s value to the DB. It’s as though the automatic reverse geocoding was not working in that case. Instead, it had to go through a UI element to “force” the conversion.

Ah well, hopefully, most of my geo-follies are behind me.