Airtable after code export

Ok so I thought I had it all figured out… I built a one-pager and connected it to airtable, exported the code but now it turns out exported code doesn’t work with airtable (and many other data sources). Honestly, considering everywhere it says that you can export code and your backend connection will keep working, it was kind of a big bummer to discover this so late in the process.

Is there either a workaround, or another alternative? I was planning on doing this workflow for many client microsites and seemed like an ideal solution since airtable is free, and these are very low-budget mini-projects that require very little ‘cms’ power…

Any ideas welcome!

How does the issue of “Airtable not working after export” manifest? Are there any logs you could share? I’m sure that would help us help you, so we’re able to provide a workaround you’re looking for.

1 Like

Thanks for your reply Broberto.

It’s actually documented (as I found out after seeing it didn’t work) that weweb uses a microservice or something to bridge between the frontend and Airtable. Once you export and selfhost, that means you can’t get data from Airtable anymore. I think it’s to protect the token from being read from the frontend…

Hello @nealzie

That is correct, Airtable will not work in exported projects since it utilizes our microservices: Hosting & Code Export | Documentation

Thanks Daniel,

So no workarounds to that? To be honest you really have to search for this info very actively. When first you read:

"Yes. WeWeb is a frontend-only tool. Your backend remains separate and is not affected by exporting or self-hosting your WeWeb project.

When you self-host the exported app, the frontend will continue to make API calls to your backend, wherever it’s hosted, just as it did before exporting."

But then in the next question, suddenly there’s a distinction between “direct connections” and “plugins”. However in the actual weweb builder, all those data sources like Xano and Airtable are grouped together, there’s no way to find out there’s any kind of distinction while building. Maybe there’s a way to present this info sooner? For example in the tooltip when you click on the datasource, like a little *info ?

What I’m now more concerned about, is that for my “big” project, I was planning on integrating Stripe. Am I correct that’s also dependent on microservices, thus weweb hosting? Is there another way to implement it, like through Xano? Would be good to know that early on.. And since Google is mentioned, does it count for the Maps widget too? What about Mapbox? That one isn’t mentioned and it wouldn’t be too late for me to switch back to mapbox now. (I switched to google maps because their Places api is so much better..)

Thanks!

1 Like

Unfortunately, no, there is no workaround, unless you use another backend as a proxy, which might defeat the purpose of using Airtable. We have been explicit about this limitation for a long time and we don’t have hidden solutions. The full list of plugins that won’t work is in the documentation. Mapbox and Google Maps are not one of them.

Plugins help but they are not mandatory to use. You can still use Stripe by connecting it to your backend, since the Stripe plugin is just for basic payments.

Ok thanks for the info! I’m not against hosting on weweb, but it’s good to know how locked-in I’ll be.. :slight_smile: