Observability with a Bubble App is not easy. Ed and the team at Habitude have built a workflow system on top of Bubble, using custom data types to describe generic workflow processes that then use Bubble’s easy integration capabilities to integrate Enterprise systems. It’s kind of Zapier on steroids, but much much more and targeted to running Enterprise Admin problems. So a lot of long-running business-critical processes, with numerous inter-system dependencies. So a great example of where Observability is vital.

The issues with observability on Bubble are

• The built-in Logs have a short retention period — 14 days on a professional plan
• There is no way to ship Bubble logs off for analysis, event detection and alerting
• Using Bubble’s inbuilt database for event logging, analysis and alerting is resource intensive — it is entirely possible to overload your Bubble app with monitoring for an overloaded app.

With Bubble, it is possible for workflows to fail mid-flow, for multiple reasons, for reasons you have no sight of or information on. There is no “system-log” with Bubble — all you have is “failed — try again”. So this is what we had to overcome in the design.

Additionally, Bubble has no concept of transactions or rollback. Workflows aren’t synchronous and sequential.

The design approach we took with Habitude was two parts;

We created a transaction system for critical workflows. Critical workflows log into a separate Bubble app “start process” and at the end of the process (which could occur asynchronously in another Backend workflow) a “completed process”. And log with it all the information needed to diagnose and retry the transaction. Within this transaction monitoring app, we detect failed transaction events that we send off to Logz.io

We use Logz.io to send log events out of Bubble — trap all workflow errors, trap all plugin errors — this stops us logging stuff into the DB and creating more load in our main applications. We use this to get observability of errors that would otherwise be silent workflow failures.

Then within Logzio we centrally analyse and alert on all these events. We chose logz.io because of its reasonable and predictable pricing.

We found that there are more silent workflow failures than we guessed — we picked up a lot of edge cases during testing that would have otherwise been invisible.

Often Privacy Rules just weren’t the first priority when first getting your app built but that priority changes as soon as you have a real customer.

Sometimes people buy a template expecting it to be fit for purpose but have no Privacy Rules, sometimes they’ve had an agency or Freelancer build their site and Privacy Rules just haven’t been implemented. Sometimes Privacy Rules are implemented that are explicit “This data is public” creating a delusion that the data is secure. Don’t worry it is fixable.

Straight from the Bubble manual …..

If you haven’t explicitly created privacy rules for a given thing, then the data is not secure.

Protecting Data

It can (and must) be fixed if you are going to store private data.

This is how I work together with Clients to implement Privacy Rules to an existing app. It could be Brokers, Patients, Customers, Dentists, Applicants, or Subscribers — it doesn’t matter who the private data belongs to or the domain of the application the same process applies.

1. Categorise every table with a prefix so that they sort into groups that make sense. For example, everything to do with Brokers, contains Brokers data — prefix with B. Another example — everything to do with Data Loading — not directly accessed by Brokers — prefix with D. Anything to do with system setup and config prefix with S. It doesn’t need to be too scientific — it is just an aid to help us make sense of all the tables. Any table you don’t understand — prefix with X — so we can sort these out later. Any table you know is an unused table — prefix with Z — so all the least useful relevant tables are at the bottom of the list. As a separate task, we will search and confirm the tables are or aren’t being used and delete or categorise however makes sense. I’d expect 5–8 groupings.

2. Figure out what roles are there. Admin is one. Brokers is another. Patients is another. Admin can see all data. Brokers can only see their own data. Are there any other roles? Roles generally have names

3. Figure out which tables are public and which aren’t. There may be some public data. There may not be some public data. It just depends. A list of states for example is probably public. Anything with personal information is almost certainly private — unless there is a specific requirement for it to be public eg a public directory listing of Brokers in a region available on the internet.

4. Check there is no personal information in Option sets. Make a list of any option sets that contains personal information. As a separate task, these will need to be converted to tables that can be protected by Privacy Rules.

5. Decide which roles see which data — going table by table (cut and paste a list into a spreadsheet so we check each one methodically). Typically it will be
- Broker sees own brokers data and can auto bind certain data
- Admin sees everything and can auto bind certain data (probably not brokers' data)
- Not logged in and everybody sees nothing. This we will make the default behaviour of the App after we have fixed the Privacy Rules.

6. Figure out if there are any schema changes required to make the Privacy Rules work. We may need to put a “broker id” of some tables to make the Privacy Rules work. Probably not if the app is working without Privacy Rules.

7. Categorise the tables into high and low risk depending on the data they contain. The highest risk tables might be User, Security Question & Answers, or anything money-related. We will look at the high risk first. We want to uncover any necessary database schema changes as early as possible.

8. Consider for each table if different roles see different fields. Using the search capability in the Bubble Editor we will check which fields are being used where. And cross-check that with our understanding of how the app works. If fields aren’t being used we will name them as marked for deletion or just delete them. Same with tables.

9. Now implement the Privacy Rules for each table in the Bubble editor.

‍

And just for good measure …..

If you haven’t explicitly created privacy rules for a given thing, then the data is not secure.

‍

Often I am asked how long does it take to integrate Bubble to a 3rd party API?

It really depends. It can be ridiculously easy or take many days of effort.

Bubble has the capabilities that make API & Product integration quick and easy.

And 3rd party Product & API’s have ways of making integration slow and complex.

Example Integration Time

To give you an idea here are some time efforts to integrate various 3rd party API’s — this is from the very start to having a useful implementation running in a Bubble App.

‍
- Jira — 30 minutes (about as easy as it gets)
- Intercom — 5–30 minutes (about as easy as it gets)
- Google SSO and Google calendar (2 hours — a lot of community information but too many API’s to wade through to figure out what is what)
- Bullhorn — an Enterprise ATS — 2 weeks (classic Enterprise API, poorly documented and very small community) — I made a plugin https://bullhorn-ats.bubbleapps.io/version-test
- Google Private Cloud Storage — 1 hour (mostly spent figuring out which of the numerous Bubble plugins to use)
- Square — embedding the SDK — 5 days (technically quite difficult ) https://square-payments-plugin.bubbleapps.io/version-test
- Square API — 20 minutes (near trivial but the API calls need some orchestration)
- Intercom — 1 hour (was mostly understanding the security settings)
- Stripe — 10 minutes,seriously, it’s effectively native to Bubble
- Google, Facebook social logins —a few minutes effectively Bubble native
- Linkedin SSO — https://linkedin-plugin-demo.bubbleapps.io/version-test — 2 hours — mostly to do with understanding Linkedin’s API and access levels
- Wonde — an Enterprise API for School Data — 2 hours, mostly understanding the organisation hierarchy and how it doesn’t paginate
- MS Graph — 4 hours of the Oauth dance and Scopes to the numerous MS API’s
- Draftable — 1 day discovering the undocumented edge cases around how the API worked. Great product though.
- Sendgrid, Postmark https://postmark-template.bubbleapps.io/version-test — 30 minutes each — I made a plugin to make it easier.
- Twilio — an hour — mostly to do with account setup
- Active Campaign — 2 hours — mostly do with setting the account up via the API
- Vimeo — a day — poorly documented API making it hard to understand the concepts — I made a plugin to make it easier https://vimeo-uploader.bubbleapps.io/version-test

Bubble Plugins

There are a lot of pre-built plugins (of varying quality) and for many things, off-the-shelf Bubble plugins exist. Integrating using a plugin typically takes 5–30 minutes. You need some credentials and basic functional understanding and you are probably already up and running. Sometimes if you understand the 3rd party API or Product already integrated using a plugin is under a minute. Hard to believe if you aren’t a Bubbler :-)

If it is a popular product with an API it’s likely Bubble already has that plugin or the top few in that category of product. Too many examples to list. https://bubble.io/plugins Try searching for Payment provider plugins — there are numerous Stripe, Square, Dwolla, Paypal, Razorpay, Xero, Transferwise, Opensea, Paystack … + a 100 others to wade through.

The issue is mostly selecting and evaluating the plugin.

If there isn’t already a plugin then the next step is ….

The API connector

The Bubble API connector is a beautiful piece of engineering and many plugins are based on it. Given a REST API, and some credentials you can integrate into an API in 5 minutes. How quickly that can be useful to you depends on the documentation of that API. Some API providers go to great lengths to make it easy to understand eg Stripe, Square, Google, Facebook, Xero.

There are plenty of badly documented API provider examples. Typically you can see the API provider has a small User base, so investing in the documentation for mass market distribution is not an investment they have made. A small User base in this case means under 5,000 users. Bubble has 2 Million users.

The worst cases are typically the documentation is a PDF dated 2012, and typically the model is something like “send a support email if you have a support contract with us and we will explain the API and how it works to you (maybe)”. Integrating these API providers typically takes a few days.

Sometimes you just get stuck trying to understand the API with the product names. Who knows the difference between “Checkout Express” vs “Stripe Connect” vs “Enterprise Light” vs “Payment Buddy V1”. 😃

As integrators, we just need to understand which one is the one we need — and no I really don’t want to book a call with you to hear how “What used to be called ‘Pay Master 2000’ is now called ‘Ezy Wallet v2’ but the documentation isn’t up to date.”

Note to Product Managers — no one is really interested or cares what you call your products. Sorry.

You can sometimes quickly hit the limits of the Bubble API Connector…

- You can not see error messages when the API connector fails (only API data level errors)
- Bubble gets confused with custom types when you have created multiple custom type versions in the same app
- You can’t manipulate lists in Post requests
- You can’t chain requests together to orchestrate complex calls
- You can’t coordinate retries with temporary errors
- You can’t use (or view) the Authentication Tokens — it’s under the covers inside the API Connector

Once you reach the limitations of the API Connector the next step is ….

Code a Plugin

Bubble plugins are what give Bubble its superpowers. You can code a Plugin (surprisingly easy, it’s just javascript and NodeJS). It. takes a bit of time and effort to get your head around how browser Events work, and how the Request object is overloaded and behaves weirdly at times. But there is a lot of community support for Plugin builders. The limit to writing plugins is that they run as AWS Lambda with 128M memory and a throttled execution time of around 20 seconds.

Once you reach the limitations of plugins then the next step is ….

Code your own API or Externalise the DB

When things get too intensive (long-running DB operations are a problem for Bubble) then you can easily integrate to an external data source. It’s a common journey people take with Bubble. Plenty of discussion on this in the forum, Xano is a popular choice. Airtable users frequently migrate to Bubble.

Old school Enterprise SOAP API’s from a PDF with no public community support can take weeks!

It’s great to work with well-documented products & APIs designed for embedding & self-service usage but many Enterprise products are not like this.😃

Some of the challenges you can face with Enterprise products are;
- getting current API documentation (which may not exist!)
- getting access to a Sandbox (which may not exist!)
- getting credentials to use the service (may take weeks, require calls, agreements, licenses)
- getting test accounts setup (may take days or weeks with a service request)
- actually write the code and implement the API (will likely take hours)
- dealing with the discovery of the quirks and undocumented features that are uncovered after integrating — can take weeks

So there’s my answer to “how long does it take to integrate Bubble with X”

More of my plugins — my Bubble Contributor profile

With Kubernetes & Containerisation a lot of your infrastructure has become code, it’s what gives us the compelling cost and efficiency benefits. This means though is there is new code to manage.

Much of what was traditionally managed in devices like firewalls, switches, virtual machines to achieve things like Segmentation, High availability, Scaling, (and a lot more) is now easily software-defined and managed as part of the application. Software is indeed eating the world.

For sure, if you are running your own Kubernetes cluster, in your own datacenters — all the traditional problems and tools still apply. Same with application code. The same patching, scanning, and monitoring of your Infrastructure and Applications still apply.

There are still the same compliance and security requirements in Kubernetes as traditional. The key point is that these new tools come with the cost and efficiency benefits of Kubernetes and Docker — less Infrastructure to manage less Infrastructure.

Googling for solutions is going to come up with multitudes of Companies and Projects clamouring for your attention. The way I make sense of it — tools generally provide either enforcement or an auditing function. Enforcement tools include things like Istio (service mesh to manage segmentation within your Cluster, SELinux container privileges). Some tools blur both roles, some try to be a suite but you need a taxonomy to make sense of it.

Within auditing tools, you have static source code analysis (linting best practice), container scanning (malware detection) and run-time anomaly detection.

Here’s my curated list of opensource auditing tools for Kubernetes and Docker.

Hadolint, static code analysis of Dockfiles. Audit best practice from “CIS Docker Benchmark v1.2.0” and helps meet PCI requirements 2.2, 6.1, 6.3

Anchore, Docker Image scanning, Malware detection to mee standard “NIST SP 800–190” and helps meet PCI requirement 2.2, 5.

Kubesec, Static code analysis of Kubernetes deployment files eg Helm charts. Audit best practice to meet standard “CIS Kubernetes Benchmark v1.5.1” and help meet PCI requirements 2.2, 6.1, 6.3

Dagda — Malware detection. ClamAV under the cover to help meet PCI requirement 5.

Falco, Runtime anomaly detection with running Pods within the cluster. ClamAV under the covers to help meet PCI requirement 5.

And if it wasn’t confusing enough, the familiar tools that fulfil security functions for a traditional environment — you can run those in Kubernetes. So things like OSSEC, Metasploit — good tools that do a valuable job in a traditional environment — you can run and manage those as containers, in Kubernetes, with the benefits of Kubernetes — and use them to manage your Infrastructure outside of Kubernetes.

If you’ve got a recommendation of other tools, or I’ve missed something — I’m keen to hear about it.