The truth? It's a disciplined, iterative process where each step builds on the last. I'm going to walk you through exactly how I built React AI UI Generator using Claude Code as my AI pair programmer—revealing every decision, every security consideration, and every lesson learned.

Whether you're a developer exploring AI-assisted development or someone evaluating how Claude Code can accelerate your workflow, this step-by-step guide will show you what's actually possible.

🔗 Want to explore the code? The entire project is open source: React AI UI Generator on GitHub. Fork it, build on it, or use it as a reference for your own Claude Code projects.

Step 1: Ship Something Real (Before Perfecting Anything)

Here's a controversial take: my first commit wasn't a planning document or architecture diagram.

It was a working application - built collaboratively with Claude Code.

Using Claude Code as my AI pair programmer, I described what I wanted to build, and together we created:

• A virtual file system (components stored in memory, not on disk - enabling instant operations)

• Real-time preview with live code transformation (changes appear instantly as you type)

• AI-powered code generation using the Vercel AI SDK (the app writes React components for you)

• User authentication and project persistence (saving your work between sessions)

• Prisma ORM with SQLite database (structured storage that scales)

Why This Approach Beats "Planning First"

Real feedback trumps theoretical planning. A working prototype reveals problems no design document can predict. You discover edge cases, UX friction, and technical constraints within days - not months.

Momentum is contagious. Teams and stakeholders see progress, not promises. That energy compounds.

Technical assumptions get validated early. Does the virtual file system actually work under load? Does the preview render correctly across browsers? You know immediately.

💡 Key Insight: Many projects fail in endless planning phases. Starting with something tangible - even imperfect - creates a foundation for meaningful iteration (repeated improvement cycles).

Step 2: Security Isn't a Feature—It's the Foundation

Here's where most developers get it wrong.

Less than 24 hours after my initial commit, the second major update focused entirely on hardening the application for real-world use.

Not new features. Security.

What I Implemented

Rate limiting (controlling request frequency to prevent abuse):

• 3 sign-up attempts per hour

• 5 login attempts per 15 minutes

• 10 API requests per hour for anonymous users

Input validation (checking that data matches expected formats) everywhere:

• Email format verification

• Password strength requirements (8+ characters, mixed case, numbers)

• Path traversal prevention (blocking attempts to access unauthorized files)

Graceful degradation (the app still works even when things go wrong):

• Demo mode for users without API keys

• Clear error messages instead of cryptic failures

File system security limits:

• Maximum 100 files per project

• 500KB per file limit

• 5MB total storage cap

• Whitelist of allowed file extensions (only .js, .jsx, .css, etc.)

Why This Matters More Than New Features

Security vulnerabilities discovered after launch are exponentially more expensive to fix. A breach in week one destroys user trust before you've built any.

🔐 Red Flag for Clients: When evaluating development partners, ask "When in your process do you address security?" If the answer is "Phase 3" or "after launch," reconsider.

Step 3: Documentation That Actually Helps (Meet CLAUDE.md)

Most documentation describes what exists.

Good documentation describes why things exist and how they connect.

I created a CLAUDE.md file—a living reference document specifically designed for AI-assisted development. This file gives Claude Code (and any developer) the context needed to make intelligent decisions aligned with the project's architecture.

How Documentation Evolved

Version 1 (Day 1): Basic commands and high-level architecture

• 100 lines of essential context

• Data flow diagrams in plain text

• Database schema (structure) documentation

Version 2 (Day 2): Security features and production guidance

• Demo mode explanation

• Rate limiting specifics

• Security feature checklist

Version 3 (Day 2-3): Multi-provider architecture

• Documentation for five AI providers

• Encryption methods for user API keys

• Complete API endpoint (access point) reference

Example: Good vs. Bad Documentation

❌ Bad: "VirtualFileSystem class in file-system.ts"

✅ Good: "The unique architecture centers on a virtual file system—components live in memory, not on disk. This enables instant file operations without I/O (input/output delays), live preview updates, user experimentation without filesystem changes, and atomic save operations (all-or-nothing database writes) to the database."

The second version tells you intent, not just location. New team members understand philosophy. AI assistants make aligned suggestions. Future maintainers don't accidentally break architectural assumptions.

Step 4: Adding Capabilities Without Breaking Things

The third day brought a major expansion: multi-provider support.

I went from one AI provider (Anthropic) to five:

• Anthropic Claude (Sonnet, Haiku, Opus)

• OpenAI (GPT-4o, GPT-4o Mini, GPT-4 Turbo)

• Google AI (Gemini 2.0 Flash, Gemini 1.5 Pro/Flash)

• OpenRouter (multi-provider access)

• xAI (Grok 2, Grok 2 Mini)

This wasn't a rewrite. It was a careful extension.

The Extension Strategy

1. Create abstractions before adding options

I introduced a provider registry (a central configuration system) that defines each provider's name, models, and settings. Adding a sixth provider later? Trivial.

2. Encrypt user data properly

Users can bring their own API keys. These get stored with AES-256-GCM encryption (military-grade encryption standard). The encryption key derives from the JWT secret (authentication token) using scrypt (a memory-hard algorithm that's expensive to crack).

Even if someone compromises the database, they can't read API keys.

3. Per-project flexibility

Each project can use different AI providers and models. Power users get flexibility. Casual users get sensible defaults.

4. Graceful fallbacks

The priority chain: environment variable → user key → demo mode.

The application always works, even when configurations are incomplete.

What This Demonstrates

Successful software evolution doesn't mean constant rebuilding. It means designing with extension points from the beginning, then using them when needs emerge.

Step 5: The User Experience Layer

Technical correctness isn't enough. The experience must feel right.

Throughout development, user-facing improvements happened alongside technical work:

Human-readable messages: Technical tool names like str_replace_editor became "Creating App.jsx"

Theme support: Dark and light modes for user comfort (and eye health during late-night coding sessions)

Project management: Rename, delete, and organize projects—features that seem obvious but make the difference between a prototype and a real tool

Thoughtful empty states: A centered, welcoming interface instead of a blank void when starting fresh

These aren't "nice to have." They're the difference between software users tolerate and software users enjoy.

Step 6: Testing for Confident Change

By project completion: 252 tests across multiple test files.

But the number matters less than the coverage strategy:

• Unit tests for core utilities (virtual file system, JSX transformation)

• Integration tests for contexts that coordinate multiple systems

• Component tests for user-facing behavior

Each test file lives alongside the code it tests (__tests__ directories). This makes adding tests when adding features a natural habit—not an afterthought.

The payoff: When multi-provider support was added, existing tests immediately caught regressions (unintended breakages) in the original single-provider behavior.

🧪 Testing Philosophy: Tests aren't about catching bugs. They're about enabling confident change. Good test coverage means you can refactor (restructure code without changing behavior) fearlessly.

The Tech Stack That Made It Possible

For the technically curious, here's what powers the application:

The choice of Vercel AI SDK was critical—it provides a unified interface for multiple AI providers, which made adding new providers trivial rather than a major refactor.

Key Takeaways for Developers

1. Start with working software. Iterate from something real, not from specifications.

2. Security early, security always. Rate limiting, input validation, and secure data storage aren't premium features—they're baseline expectations.

3. Document the why, not just the what. Future you (and your team) will thank present you.

4. Design for extension. Abstractions like provider registries make future changes straightforward.

5. User experience is code quality. Clean internals that produce confusing interfaces aren't actually clean.

Key Takeaways for Clients and Decision-Makers

When evaluating development approaches or partners, ask:

How quickly do they produce working software? Plans are cheap; working systems are evidence of capability.

When do they address security? If security is a "phase 3" concern, that's a red flag.

How do they handle documentation? Good documentation suggests good thinking about systems and their users.

How do they manage complexity? Adding five AI providers without rewriting the application demonstrates architectural foresight.

Do they ship incrementally? Six focused commits over three days shows discipline. Sixty commits or three months of silence both suggest problems.

The Bottom Line

Building production-ready software with Claude Code isn't about letting AI do everything. It's about human-AI collaboration—maintaining discipline while leveraging AI to accelerate execution.

This project evolved from a single-provider prototype to a multi-provider, security-hardened application with comprehensive documentation and 252 tests.

What Claude Code excelled at:

• Scaffolding boilerplate code quickly

• Implementing security patterns correctly

• Writing comprehensive tests

• Maintaining consistency across files

What still required human judgment:

• Architectural decisions

• Security priorities

• User experience choices

• When to stop adding features

The techniques aren't secret:

• Start with something working

• Prioritize security

• Document thoughtfully (CLAUDE.md!)

• Extend rather than rewrite

• Never forget that real humans will use what you build

The difference between amateur and professional development isn't talent—it's consistency in applying these principles, project after project.

📦 Get the Code

The entire project is open source and available for you to use, learn from, or build upon:

🔗 GitHub Repository: github.com/nocodeanish/react-ui-generator

• ⭐ Star the repo if you find it useful

• 🍴 Fork it to build your own version

• 🐛 Open issues for bugs or feature requests

• 🤝 PRs welcome!

Built with Claude Code, iterative development, and a commitment to shipping software that actually works.

Connect & Continue the Conversation

Found this useful? I'd love to hear about your development process. What's your approach to balancing speed with security?

☕ Buy me a coffee if this helped you!

Tags: #claudecode #ai #react #nextjs #typescript #webdev #programming #tutorial #fullstack #anthropic #aitools #softwaredevelopment

TL;DR

Bubble.io doesn’t natively support TOTP-based two-factor authentication (2FA) - the kind used by Google Authenticator and Authy - because it lacks built-in tools for generating secret keys, verifying time-based codes, and performing cryptographic operations.

To overcome this, you can use the Crazy Two Factor – Authentication Plugin, which enables you to:
✅ Generate and verify TOTP codes directly in Bubble
✅ Display QR codes for users to scan with any authenticator app
✅ Implement full 2FA flows (enable, verify, login) without any external APIs

This plugin-based approach keeps everything inside your Bubble app — making it secure, efficient, and easy to maintain, while providing a professional-grade authentication experience comparable to SaaS-level systems.

This article is Powered by Zeroic and Sponsored by FormulaBot.

Limitations of Bubble.io’s native 2FA:

Bubble.io’s built-in two-factor authentication (2FA) primarily revolves around sending verification codes via email or SMS. While this works for basic identity verification, it doesn’t cover the TOTP (Time-Based One-Time Password) standard - the system used by popular authentication apps like Google Authenticator, Authy, or Microsoft Authenticator.

TOTP works differently from email or SMS verification. Instead of sending a code over the internet or through a messaging service, it relies on a shared secret key that’s stored both on the server (Bubble app) and the user’s device (in the authenticator app). This key generates a new 6-digit code every 30 seconds entirely offline, meaning no communication between your app and the authenticator is needed during verification.

Here’s the challenge:
Bubble’s native user authentication system doesn’t provide:

• A way to generate and share the secret key securely with the user.

• Built-in tools for generating or verifying TOTP codes.

• Access to low-level cryptographic functions (like HMAC-SHA1) is needed to calculate time-based tokens.

Because of these missing components, developers can’t directly implement app-based verification like TOTP purely through Bubble’s native features.

This limitation makes it difficult to offer the same security and convenience that users expect from standard authenticator-based 2FA systems - where verification doesn’t depend on email delivery, SMS reliability, or network access.

Advantages of using the Plugin over the API

Implementing TOTP (Time-Based One-Time Password) authentication manually inside Bubble can be quite complex. You’d need to handle several technical layers yourself - like generating the secret key, creating a QR code for users to scan with Google Authenticator, calculating time-based codes using cryptographic algorithms (HMAC-SHA1), and then verifying those codes securely when the user logs in.

While it’s possible to achieve some of this using custom JavaScript or backend workflows, the process is time-consuming, error-prone, and security-sensitive. That’s where a dedicated plugin comes in handy.

A good plugin encapsulates all these technical details behind simple Bubble actions - so you can set up TOTP-based 2FA with just a few workflows instead of writing and testing custom code.

Another big advantage is that you don’t need to register your app with third-party authentication providers like Auth0 or Stytch. These platforms require API keys, account setup, and extra configuration steps - and in many cases, their APIs come with usage limits or ongoing subscription costs.

By using a Bubble-native plugin, your entire 2FA system remains self-contained inside your Bubble app. This means:

• No dependency on external APIs or services.

• Faster setup - everything happens inside Bubble.

• Lower long-term maintenance, since you’re not managing third-party credentials or webhooks.

So, as a plugin has a one-time fee, it often pays for itself quickly in saved development hours, reduced complexity, and a cleaner, more maintainable authentication setup.

Here, I will provide a step-by-step guide to implement TOTP(time-based one-time passwords) based two-factor authentication (2FA) that will be compatible with popular authenticator apps such as Google Authenticator, Authy Authenticator, and Microsoft Authenticator.

Step 1: Install Crazy Two Factor - Authentication Plugin in the bubble.io app

You can find the plugin here.

Step 2: Setup TOTP based 2FA Enabler for User in bubble.io app

Here, I have set this up on the user’s profile page, where the user can enable 2fa with switch toggle.

Once the switch is Yes, There is an action named ‘Two Factor’ from plugin, Use it to enable 2fa. Enabling 2fa won’t require secret and verification token as you can see in the screenshot below. You can write any text as an app name. This name will be shown in your authenticator app.

Now create 4 new field’s in User table named secret, is-2fa-enabled, is-2fa-verified and is-2fa-qr-code. All this field will be used in next step.

So bascially this ‘Two Factor’ action is generating QR code and secret which will be used to enable TOTP based 2fa for user. is-2fa-verified is ‘no’ because user just have enabled it but verification is still pending.

Step 3: Setup TOTP based 2FA Verifier for User in bubble.io app

Now Create a Group where this 2fa-qr-code will be shown and User will be asked to scan the QR code in authenticator app such as Google Authenticator and Write 6 digit token number in input box to verify as shown in the image below. This group will be shown immediately once the is-2fa-enabled is ‘Yes’.

Once the 6 digit token is provided and verification button is clicked, Run ‘Two factor’ action again. This time, it will be to verify and not to enable. Here is the setup image below

Now result of this action is either error or return data. If the result’s error detail is not empty → Show error to user below QR code or wherever you want.
If the result’s Return data is not empty→ Make is-2fa-verified ‘Yes’. Check the image below

Step 4: Setup Privacy rules for User table

Now, all the fields of user table must be protected by privacy rules. So logged out user’s details won’t be visible in network calls or concole app file. But I will make user table details find in searches enabled. Basically When will make ‘Do a search for user’ call, it will give me result but data will be empty because I can find the user in search but data is privacy protected.

Step 5: Setup login mechanism for 2fa-verified=Yes User

Once the user writes email and password on login page, check whether user has 2fa-enabled or not. I am checking it using custom event and returning data as yes or no.

If the search result is empty, the return data will be no and If the search reult is not empty, the return data will be Yes.
If the return data is yes, then on click of login, don’t ‘Log the User In’ but show verify group first ask for 6 digit verification token.

Once the input is not empty, Allow user to click continue button.
Log the user in and verify 6 digit verification code using ‘Two Factor’ action.

If the result of the ‘Two Factor’ action has an error detail not empty → Log the user out immediately.
If the result of the ‘Two Factor’ action has result data not empty → Keep user logged in.

This approach not only simplifies the setup process but also maintains the entire authentication system within the Bubble environment, reducing dependencies on third-party services and minimizing long-term maintenance. Ultimately, this method provides a more secure, efficient, and user-friendly authentication experience.

Key Takeaways: Implementing TOTP-Based 2FA in Bubble.io

• Bubble.io’s native 2FA supports only email and SMS verification - not TOTP-based authenticator apps.

• TOTP (Time-Based One-Time Password) works completely offline and generates new 6-digit codes every 30 seconds using apps like Google Authenticator, Authy, or Microsoft Authenticator.

• Bubble lacks native cryptographic functions like HMAC-SHA1, which are required to generate and verify time-based one-time passwords.

• The Crazy Two Factor – Authentication Plugin provides a simple and secure solution to enable TOTP 2FA inside Bubble without using any external APIs.

• The plugin handles all critical steps - secret key generation, QR code creation, and token verification - directly within Bubble workflows.

• Advantages of using the plugin:

  • No dependency on external APIs like Auth0 or Stytch

  • Faster and simpler setup

  • Lower maintenance and better control over security

• Developers can easily add workflows to enable, verify, and enforce 2FA for users with just a few actions.

• Applying strong privacy rules in the User data type ensures user secrets remain secure.

• This method keeps the entire authentication system Bubble-native, providing a robust, user-friendly, and scalable security flow.

Frequently asked questions (FAQs)

Q: What is TOTP-based 2FA?

A: TOTP (Time-Based One-Time Password) is a form of two-factor authentication where a unique 6-digit code is generated every 30 seconds by an authenticator app like Google Authenticator, Authy, or Microsoft Authenticator. It’s more secure than SMS or email-based 2FA because it works entirely offline and cannot be intercepted.

Q: Does Bubble.io natively support TOTP-based 2FA?

A: No, Bubble.io’s native authentication system only supports email or SMS verification codes. It doesn’t include built-in support for TOTP-based authentication or cryptographic tools like HMAC-SHA1 needed to generate time-based tokens.

Q: Why not just use Bubble’s built-in 2FA feature?

A: Bubble’s native 2FA is fine for simple verification but lacks flexibility and security features like offline token generation, authenticator app compatibility, and customizable verification flows. TOTP-based 2FA offers stronger security and a smoother user experience.

Q: Can I build TOTP-based 2FA in Bubble without using any APIs?

A: Yes, you can! By using the Crazy Two Factor – Authentication Plugin, you can implement a fully functional, app-based TOTP 2FA system without integrating external APIs like Auth0 or Stytch. The plugin handles secret generation, QR code creation, and verification directly within Bubble.

Q: Is the plugin better than using an API?

A: Yes, for most Bubble developers. The plugin simplifies setup, avoids third-party dependencies, and keeps your entire authentication system within the Bubble ecosystem. APIs like Auth0 add configuration overhead, require account registration, and often charge usage-based fees.

Q: Is the plugin secure?

A: Yes. The plugin uses secure key generation and verification methods that align with standard TOTP algorithms. However, you should still apply strict privacy rules to your User data type to protect sensitive fields like secret and is-2fa-verified.

Q: Can users disable 2FA once enabled?

A: Yes. You can add a simple workflow that resets the user’s is-2fa-enabled, is-2fa-verified, and secret fields to blank values. This allows users to turn off 2FA when needed.

Q: Does this work with all authenticator apps?

A: As per plugin creator, It's a JavaScript library designed for generating and verifying One-Time Passwords (OTPs). The plugin is specifically compatible with popular authenticator apps such as:
- Google Authenticator
- Authy Authenticator
- Microsoft Authenticator

Formula Bot has sponsored this article - Formula Bot is your AI-powered data analyst that instantly transforms data into charts, insights, reports, and more. Here is the link to check it out.

This article is powered by the dev team behind FormulaBot - Zeroic, a low-code and AI development studio. Here is the link to check them out.

TL;DR

• Problem: Move parents (data_type_1) and children (data_type_2) between Bubble apps while preserving the relation (parent list of children & child’s single parent).

• Approach: Read all parents from App-1, compare with App-2, create missing parents in App-2, fetch each parent’s children from App-1, create children in App-2, then patch parent records in App-2 to reference created children IDs.

• Tool: n8n workflow (manual trigger → HTTP GET App1/App2 → dedupe → batch create → create children → merge → update relationships).

Challenges in relational database migration

• Duplicate prevention - avoid creating the same parent twice in App-2.

• Unique ID mapping - Bubble object _id values differ between apps; you must map App-1 IDs → App-2 IDs to reconstruct relations.

• List vs single fields - parent often stores a list of child IDs, child stores a single parent reference. Both directions must be kept consistent.

• API constraints & rate limits - Bubble APIs can be rate-limited; batch and sleep strategically.

• Data shape differences - field names (or types) may differ; must transform payloads.

• Atomicity - multi-step migrations can partially succeed; plan for resume/rollback (store mapping and logs).

Why use n8n for data migration?

• No-code glue: HTTP nodes + code nodes let you call the Bubble REST API and transform payloads visually.

• Batched processing: the splitInBatches node handles large datasets safely and avoids rate-limit bursts.

• Custom logic: Code nodes for dedupe/formatting relations are simple JS.

• Visibility & re-run: You can re-run failed batches and inspect inputs/outputs.

• Extendability: Same pattern works to migrate between Bubble ↔ Supabase ↔ Xano, etc (just change endpoints/auth and payload shape).

Pre-requisite setup in Bubble (what to prepare before running the workflow)

• Admin API keys (or API token) for both apps:

  • Create API keys / set the proper endpoint access in Bubble (Settings → API if required). Ensure the token has create/read/patch permissions for the data types in question.

• Enable Data API on both apps (Settings → API → check Expose Data API for each Data Type you’ll use).

• CORS / IP - If you restrict IPs, add the n8n server IP or run n8n where it can reach Bubble.

• Field mapping document - record field names in App-1 and App-2 for each data_type. (e.g., field_1, _variants_list_custom_data_type_2, field_name_text, etc.) Sample n8n JSON references names - confirm they match your bubble types.

• Backup - export both data sets (Data → App Data → Export) before running the migration.

• Test environment - always run on staging apps first.

• Decide mapping storage - either keep mapping in n8n run data or write a temporary mapping table in App-2 (recommended for large runs).

n8n Setup for data migration explained with an example

Use this JSON file as a blueprint

Note: replace app1domain.com and app2domain.com With your actual Bubble app API hostnames and set the credentials referenced in the JSON.

1) Manual trigger

• Node: When clicking ‘Execute workflow’ (manualTrigger)

• Purpose: Start the migration manually so you can control the run.

2) Get all parents from App-1

• Node: Get data_type_1 data - App 1 (HTTP Request GET → https://app1domain.com/api/1.1/obj/data_type_1)

• Important settings:

  • Authentication: HTTP Bearer (use your Bubble API token).

  • Keep default GET, no constraints for first full read (unless you want partial).

• Output: JSON response with response.results array.

3) Get all parents from App-2 (to detect duplicates)

• Node: Get data_type_1 data - App 2 (HTTP Request GET → https://app2domain.com/api/1.1/obj/data_type_1)

• Purpose: get existing records on the destination, so we create only the missing parents.

4) Filter missing parents (Code)

• Node: Filter list of Missing data in app2 (Code node - JS)

• Code logic (from sampleJSON): it loads App1 & App2 results, extracts field_name_text from App2 and filters App1 for entries not present in App2.

• Action: this returns items representing parents that need creation in App-2.

• You must verify the key used to compare uniqueness (field_name_text in the sample workflow). Replace with the real uniqueness field (e.g., slug, email, name) if different.

Snippet used:

const app1 = $item(0).$node["Get data_type_1 data - App 1"].json.response.results;
const app2 = $item(0).$node["Get data_type_1 data - App 2"].json.response.results;
const app2Ids = app2.map(t => t.field_name_text);
const missing = app1.filter(t => !app2Ids.includes(t.field_name_text));
return missing.map(t => ({ json: { field_name_text: t.field_name_text } }));

5) Batch loop for creating missing parents

• Node: loop create data_type_1 in app2 (SplitInBatches)

• Purpose: process missing parents in small batches. Suggested batch size: 10–50, depending on API limits.

Important: set batchSize appropriately and use wait between requests (or add a Wait node) to avoid rate limits.

6) For each missing parent, fetch the full parent from App-1 and fetch its children

• Node (parallel outputs):

  • Fetch individual data_type_1 from app1 - HTTP GET to https://app1domain.com/api/1.1/obj/data_type_1 with constraints A query that finds the parent by the uniqueness field. The JSON query expression in the sample workflow is:

      constraints = JSON.stringify([{ key: "id_name_text", constraint_type: "equals", value: $json.id_name_text }])
    

    Replace id_name_text with your actual unique key.

  • Create data_type_1 in app2 - HTTP POST to https://app2domain.com/api/1.1/obj/data_type_1 with a JSON body mapping the fields from App-1 response to App-2 fields. Sample workflow uses:

      {
        "field_1": {{ $json["response"]["results"][0]["field_1"] }},
        "field_2": "{{ $json['response']['results'][0]['field_2'] }}",
        "list_of_field_3": {{ JSON.stringify($json["response"]["results"][0]["list_of_field_3"]) }}
      }
    

    Update field_1/field_2/list_of_field_3 to match actual fields.

Why are both parallel? You create the new parent in App-2 and also fetch the parent’s children (next step) - both outputs are merged later.

7) Fetch child data for that parent in App-1

• Node: Fetch child data (data_type_2) from app1 - HTTP GET to https://app1domain.com/api/1.1/obj/data_type_2 with a constraint in on parent’s _id list (see sample JSON).

• Example query in sample workflow:

    constraints = JSON.stringify([{ key: "_id", constraint_type: "in", value: $json["response"]["results"][0]["_variants_list_custom_data_type_2"] }])
  

  Replace the key "_variants_list_custom_data_type_2" with the actual parent → child list field in App-1.

8) Merge parent-create output + fetched children

• Node: Merge - combines the Create data_type_1 in app2 output and the Fetch child data output so the workflow has both the new parent’s App-2 result and the list of App-1 children to create.

9) Create child records in App-2

• Node: Create data_type_2 in app2 - HTTP POST to https://app2domain.com/api/1.1/obj/data_type_2

• Payload example from sample JSON:

    {
      "_field_1": $json.id,
      "isactive_boolean": $json["response.results"]["isactive_boolean"],
      "field_2": $json["response.results"]["field_2_text"]
    }
  

  • _field_1 should store the parent reference (use the new parent id returned from App-2 - ensure you capture it).

  • If the child needs to reference the parent via Bubble relation, send the correct field (usually the parent’s _id or list field format expected by Bubble.

Important: the code in the sample workflow sets field_id via a Set node, which stores the created record ID for later mapping. Make sure you capture and persist App1_parent_id -> App2_parent_id the mapping somewhere (either in a temporary data type in App-2 or as a file). The Set node in the sample flow does field_id = $json.id - Adapt the name to your types. Data Migration from One Bubble …

10) Merge App-2 child & parent rows into relation format

• Node: Merge app2 data_type_2 and data_type_1 in single json - combines created child responses and created parent responses into one stream.

• Node: Change format of data for relation (Code node) - the JS groups children by parent id and creates an object like:

    { json: { data_type_1_id: dataType1Id, data_type_2_ids: [ ... ] } }
  

  This is exactly what you need to PATCH the parent record in App-2 with the list of child IDs.

Code used in sample workflow (copy/paste):

const items = $input.all();
const grouped = {};
for (const item of items) {
  const dataType1Id = item.json.data_type_1_id;
  const dataType2 = item.json.data_type_2;
  if (!grouped[dataType1Id]) { grouped[dataType1Id] = new Set(); }
  grouped[dataType1Id].add(dataType2);
}
const output = Object.entries(grouped).map(([dataType1Id, dataType2Set]) => ({
  json: {
    data_type_1_id: dataType1Id,
    data_type_2_ids: Array.from(dataType2Set),
  }
}));
return output;

(Modify data_type_1_id / data_type_2 keys to match your payload names.)

11) PATCH parent in App-2 to update the relationship (list of children)

• Node: Update Relationship between data_tytpe 1 and data_type 2 (App 2) - HTTP PATCH to https://app2domain.com/api/1.1/obj/data_type_2/{{ $json.data_tyep_1_id}} (note: fix typo data_tyep_1_id → data_type_1_id).

• Body example from JSON:

    {
      "_variants_list_custom_data_type_2": $json.variant_ids
    }
  

  Replace _variants_list_custom_data_type_2 with your parents’ list field name in App-2 and variant_ids with the array produced by the previous code node (e.g., data_type_2_ids).

Important fixes & checks

• Ensure mapping: when creating child records in App-2, capture their returned id and attach the created child ID to the mapping item so the code node can group them.

Practical tips, gotchas & recommended config

• Batch size: Use conservative sizes (10) and increase only after testing. Add a small Wait (1s) after each POST if you hit rate limits.

• Logging: store each created mapping row in a temporary Bubble data type migration_mapping with fields app1_id, app2_id, type, status. This helps resume if something fails.

• Idempotency: make API POSTs idempotent by checking uniqueness before creating (as your code does by listing App-2 first). Also, consider creating a unique external_id field to catch duplicates later.

• Field type conversions: arrays/lists must be JSON.stringify(...) in your POST bodies (workflow already does that in examples).

• Testing flow: run with 3–5 sample parents first, inspect results, then full run.

• Rollback plan: if needed, delete the created App-2 records using the stored mapping.

How does this logic extend beyond Bubble.io?

The pattern is generic:

1. Read source rows via API (App-1 / Supabase / Xano).

2. Read destination existing rows to skip duplicates.

3. Create missing parents on the destination.

4. For each parent, fetch children from the source and CREATE them on the destination.

5. Build a mapping of source_id -> dest_id.

6. PATCH parents on the destination to attach children IDs.

Change points when migrating to other DBs:

• Auth: use Bearer/token for Bubble; Supabase uses service_role key; Xano uses its token - n8n HTTP nodes handle each.

• Endpoints & payload shapes: adapt POST/patch body to each API’s contract (Supabase expects POST /rest/v1/<table> with headers apikey + Authorization and Prefer: return=representation to get created IDs).

• Batching & bulk insert support: Supabase supports bulk inserts - use that to speed up child creation (but still capture returned IDs).

• Relationship formats: relational DBs use foreign keys rather than a list of IDs. For relational DBs, you will set a foreign key on the child row to the parent ID (simpler than patching the list on the parent).

Frequently asked questions (FAQs)

Q: Can I migrate large datasets (10k+ records) with this n8n flow?

A: Yes — but use batching, temporary mapping storage, and run in stages. Monitor rate limits and use splitInBatches with conservative sizes (e.g., 50).

Q: How do I ensure no duplicates in App-2?

A: Compare a unique field (slug/email/external_id) from App-1 with App-2 before creating. Optionally store an external_id On App-2 to mark the origin.

Q: Do I need to write code?

A: Minimal JS is used inside n8n Code nodes for grouping/deduping - copy/paste snippets provided in this guide. No external scripts required.

Q: What if field names differ between apps?

A: Map fields explicitly in the Create POST node bodies; use JSON.stringify() for lists and use Code nodes to reshape data.

Q: How to resume a partially failed run?

A: Keep a migration_mapping (or use the mapping Set node) that stores successful app1_id -> app2_id. Filter already migrated parents out on rerun.

Q: Is it safer to create children first or parent first?

A: Create the parent first (to get its App-2 ID), then create children attaching that parent id. After all children are created, patch the parent with a list if your data model requires it.

Quick checklist before pressing Execute

• Export & backup both app data.

• Confirm API tokens for both App-1 and App-2 in the n8n credentials.

• Update all domain placeholders app1domain.com / app2domain.com.

• Adjust the uniqueness key used in the dedupe code (field_name_text in your flow).

• Fix typos in node templates (data_tyep_1_id → data_type_1_id).

• Set safe batchSize (start small).

• Add mapping persistence (recommended).

• Run 3–5 sample parents and validate.

Bubble API Workflow Limits

• Bubble’s workflows (especially when calling an external API) are subject to timeout constraints -many users encounter errors like Failed to establish a connection after 30000 ms or request timed out When the external call takes longer.

• Some forum discussion suggests that Bubble has a 5-minute limit on entire workflow sequences, but the more immediate bottleneck is the ~30s external API call ceiling.

• This means that merging multiple or large PDF files inside a Bubble workflow is inherently risky - you might hit failures when the backend process takes too long or the HTTP request to an API doesn't respond fast enough.

Because of that, I decided to offload the process into a dedicated automation environment (n8n) so that Bubble just orchestrates inputs and gets the merged result back.

Bubble PDFs Merge using n8n Architecture

Here’s the improved design, refined with caveats:

Bubble → n8n (Webhook Trigger)

• Bubble sends the list of PDF URLs + metadata to an n8n webhook (HTTP Request).

• To avoid Bubble waiting indefinitely, the webhook should respond quickly (e.g. acknowledge receipt).

• Later, n8n will call back Bubble with the merged file link.

n8n: PDF Download & I Love PDF Merge

• Use n8n nodes (HTTP Request, Function, Loop) to download each PDF file.

• Use I Love PDF Merge API (start merge task → upload each file → execute merge).

• Store credentials (I Love PDF API key) securely in n8n’s credentials system, not in nodes.

n8n: Upload Merged PDF to Bubble File Manager

• Use Bubble’s /fileupload endpoint to push the merged file.

• Security warning: Bubble’s file upload API endpoint can be abused if left open. Many in the Bubble community call this a vulnerability.

• To protect this, ensure only your backend (n8n) can call it (e.g., with a secret header, IP whitelisting, or checking an authorization token).

n8n → Bubble: Callback / Workflow Trigger

• After upload, n8n calls a Bubble API endpoint (e.g. a backend workflow) passing the file URL or file ID.

• Bubble updates its database and triggers subsequent workflows (e.g. emailing the PDF).

Error Handling / Retries

• If any PDF upload or merge step fails, n8n can retry.

• You can notify the admin or fallback logic inside n8n if something goes wrong.

Why This Bubble + n8n Solution Works Better?

• No Bubble timeouts on heavy processing - n8n can run as long as needed without the same constraints.

• Separation of concerns - Bubble remains the UI and data orchestrator; heavy file processing is handled elsewhere.

• Credential safety - API keys remain in n8n’s credential store, not exposed in visuals.

• Better error control - n8n supports structured retry logic, branching, error-handling, logging etc.

However, you need to be cautious about:

• Ensuring the initial webhook from Bubble doesn’t block (i.e., respond quickly, don’t wait for the full merge).

• Securing Bubble’s file upload endpoint so that malicious actors can’t upload arbitrary files.

• Handling edge cases (network failures, large file sizes, etc.) robustly.

Security & Best Practices

• Always use n8n’s credential store (not embedding secrets in nodes). n8n’s docs specify credentials are separate and private.

• For your Bubble file upload endpoint:

  • Avoid leaving it wide open. Many community posts state that the /fileupload endpoint can be triggered without authentication in some setups.

  • Use headers or tokens to limit who can upload.

• For Bubble → n8n webhook:

  • Validate incoming requests (signature, token) to prevent unwanted triggers.

  • Return a fast ACK, then process asynchronously.

• Ensure your callback from n8n → Bubble is also authenticated/validated.

n8n template for PDF Merger

Here is the logic structure:

Bubble frontend → HTTP POST to n8n webhook (pdfUrls, metadata)
↓
n8n: Webhook receives → immediately respond 200 OK (maybe return a job ID)
↓
n8n: Process flow
    • Authenticate with I Love PDF (using secure credential)
    • Start merge task
    • For each URL: download and upload to merge task
    • Execute merge → get merged PDF URL
    • Download merged PDF
    • Upload to Bubble fileupload endpoint (with authorization)
↓
n8n → HTTP POST back to Bubble backend workflow endpoint: pass merged file URL & job ID
↓
Bubble backend workflow: update DB, trigger email or next step

Here is the template to import: Click here to request access.

TL;DR

Daisy Chain Filtering in Bubble.io is a client-side filtering technique where each filter input (like dropdowns or checkboxes) updates a shared custom state. As users select options, each filter refines the results based on the previous ones - forming a seamless, chained filtering logic.

This method avoids heavy searches or backend workflows and enables fast, dynamic filtering - ideal for datasets under ~1,000 records. You’ll use conditional visibility, custom states, and custom events to build the logic.

What is Daisy Chain Filtering?

Daisy chain filtering is a technique where multiple filters are applied in a specific sequence, one after another, to progressively narrow down a list of results. Each filter takes the output of the previous step and applies an additional condition, creating a “chain” of filters.

In Bubble.io, this is typically done using repeated :filtered operations on a list, instead of filtering everything at once or using database constraints.

How to implement Daisy Chain Filtering in bubble.io?

I will guide you through a step-by-step process to implement Daisy Chain Filtering in bubble.io with an example given below.

Step 1: Create UI for filters

As you can see in the image above, I am using the following elements in bubble.io for filtering the data of the Repeating Group of products.

Step 2: Set custom states for each filter

For each filter, I am setting a custom state on the Page.

Step 3: Load all data in the Popup Hidden variable as base data

As you can see in the image, I am loading all the product data on the page

Step 4: Set the source of the repeating group on the page

Set the VAR RG ALL Products as the data source of the Repeating Group, where filtered results will be displayed.

Step 5: Set up 6 custom events for 5 filters

As you can see, I have numbered it 00 to 05.

• 00 is for setting up base data

• 01 to 05 for each custom event for each filter

Step 6: Set up a 00 custom event to load basic data in the Repeating Group

As you can see in the image, first, I am displaying base data in the Repeating group and triggering the 01 custom event

Step 7: Set up a 01 to 05 custom event to filter the Repeating Group data based on active filters

As you can see in the 00 Filter workflow, the 01 workflow is triggered in the end. Repeat this process for workflows 01 to 04.
So,

• Custom ‘00 Filter’ workflow will trigger ‘01 Filter’ workflow

• Custom ‘01 Filter’ workflow will trigger ‘02 Filter’ workflow

• Custom ‘02 Filter’ workflow will trigger ‘03 Filter’ workflow

• Custom ‘03 Filter’ workflow will trigger ‘04 Filter’ workflow

• Custom ‘04 Filter’ workflow will trigger ‘05 Filter’ workflow

Now, as you can see in the image attached in step 5, I have assigned each custom event from 01 to 05 for each filter.

• Custom ‘00 Filter’ workflow is base data loading custom event

• Custom ‘01 Filter’ workflow is an Input filter custom event

• Custom ‘02 Filter’ workflow is a price range filter custom event

• Custom ‘03 Filter’ workflow is a brand filter custom event

• Custom ‘04 Filter’ workflow is a category filter custom event

• Custom ‘05 Filter’ workflow is a location filter custom event

On 01 to 05 custom events, before triggering the next event, use the action ‘Display data in Repeating Group’ with the condition that if the filter value is not empty, then run this action. Just as shown in the image below:

Step 8: Trigger 00 Custom event after every action of setting the custom state for filters

As you can see in the image below, I am adding a category in custom state when the user selects a category from the category dropdown. In the next action, I am triggering the 00 Custom event

Similarly, Trigger 00 custom event after all actions, whenever the value of the custom state for any filter changes.

And here your daisy chain filter is ready. Now, let’s understand how this will work

How this Daisy chain filter will be executed?

Let’s understand this in a step-by-step flow chart manner:

1. User selects a filter (e.g., Brand = Nike)

2. Custom state is updated (brand = "Nike")

3. Trigger "00 Filter" → loads all products

4. Triggers "01 Filter" (Input) → skips if empty

5. Triggers "02 Filter" (Price) → skips if not set

6. Triggers "03 Filter" (Brand) → filters by brand = "Nike"

7. Triggers "04 Filter" (Category) → skips if not selected

8. Triggers "05 Filter" (Location) → skips if not selected

9. Final result shown in the Repeating Group Products

❓ Frequently Asked Questions

Q1: Your "Daisy Chain" method feels very fast once the data is loaded. But what happens when my database grows from 200 products to over 10,000? Is this client-side method still the best choice?

This is a crucial question for any growing application. The Daisy Chain method is exceptionally fast for user interactions after the initial data is loaded. However, its scalability is limited.

• For Small Datasets (< 500 items): This method is excellent. The initial load time in Step 3 is negligible, and the instant filtering provides a fantastic user experience.

• For Large Datasets (> 1,000 items): The initial step of loading all items into a custom state becomes a major performance bottleneck. A user might have to wait a long time for 10,000+ items to download to their browser, and on lower-powered devices, this could even crash the browser page.

My Recommendation:

• For large datasets, you must switch to server-side filtering. This means your Repeating Group's data source should be Do a search for Products, with the constraints dynamically referencing your filter inputs (e.g., Brand = Dropdown Brand's value). Use the "Ignore empty constraints" feature to build a single, powerful search query that only downloads the exact data needed from the server.

• When your filtering logic is too complex for standard server-side constraints, you should use the hybrid approach. Here is an example:

  • Filtering Based on a Calculation: This is the most common use case. You want to filter based on a value that is calculated from two or more fields on the same data entry.

    • Example: You have a Product with regular_price and a sale_price. You want to show only products that are "more than 20% off." The required filter logic is sale_price < regular_price * 0.8. You cannot perform this calculation within a Do a search for... constraint.

    • Hybrid Solution: First, do a server-side search for all products in the relevant category (e.g., Category = "Shoes"). Then, apply a client-side :filtered with a Advanced: condition: This Product's sale_price < This Product's regular_price * 0.8.

• Here is the golden rule for filtering in Bubble for Large Datasets:

  Filter as much as possible, as early as possible, on the server.

  Use the standard constraints in your Do a search for... to do all the heavy lifting. Get the dataset as small as you possibly can before it ever leaves the database.

  Only use the hybrid approach as a final step to perform a specific calculation or logical check that is impossible to do on the server. It is a powerful tool for complex situations, but relying on it for simple filters is an anti-pattern that will lead to performance issues as your app scales.

Q2: This article mentions saving Workload Units (WU) by avoiding multiple "Do a search for" calls. How does the WU cost of this method compare to a single, optimized server-side search?

You're right that this method cleverly avoids the high WU cost of running multiple separate searches and merging them. However, it's a trade-off. Let's compare:

1. Daisy Chain Method: The main WU cost is in Step 3: Load all data. Loading a table with X number of items, even with minimal fields, can consume a significant amount of WU in a single burst. After that, all the :filtered Operations are free as they happen on the client.

2. Server-Side Method: A Do a search for... with several constraints is extremely efficient. The WU cost is proportional to the final number of results returned, not the total size of the database table.

My recommendation:

• For small to medium Datasets, this method is likely more WU-efficient.

• For large tables, a single, well-constrained server-side search is almost always more WU-efficient and infinitely more performant because the cost is based on the small, filtered result set, not the entire database table.

Q3: Are there any security implications of loading all product data into a custom state on page load, as shown in Step 3?

Yes, and this is the most critical consideration. Any data loaded onto the page - even if held in a hidden variable or custom state - is fully accessible to a savvy user via their browser's developer tools.

Imagine your Product data type also has fields like cost_price or internal_notes. Even if you don't display these fields in the repeating group, by loading the "full list of Products" to the client, you are sending that sensitive data to every user.

Rule of Thumb: Never use client-side filtering for data that isn't 100% public. The only way to truly secure data is to use Bubble's Privacy Rules to define what data a user is allowed to see and server-side search constraints to ensure only that permitted data is ever sent from the database.

Q4: When Does Daisy Chain Filtering Make Sense in Bubble.io?

I want to get ahead of a common (and valid) reaction:

“Why not just use a single Do a search for with ignore empty constraints?”
So here’s a breakdown of when I think Daisy Chain Filtering (DCF) is a useful tool and when it’s not.

❌ When Not to Use Daisy Chain Filtering

Daisy chaining is a client-side pattern, which means:

• All data is loaded into the browser first (:filtered is evaluated client-side)

• Filters apply after page load, meaning initial data transfer can be large

• It exposes all fields (not protected by privacy rules) of all loaded records, which could risk data leaks

• It doesn’t scale well for large datasets (>1,000 records, depending on complexity)

• It increases initial memory usage and may freeze or crash low-resource devices

So if you're working with:

• Dynamic but searchable constraints (e.g. text contains, category is, status is not)

• Data that can safely be retrieved directly from the server

• A need for server-side filtering or pagination

👉 Then, yes - a standard Do a search for with "Ignore empty constraints" is the best and most scalable choice. No argument there.

✅ When Daisy Chain Filtering Can Be the Better Option

That said, DCF isn’t a mistake - it’s a targeted tradeoff. It works best when:

• You have a bounded dataset (~<1,000 records) that is safe to load into the browser

• You want ultra-fast interactions, especially when filters are toggled in rapid succession

• You need complex filter logic that Bubble can’t express server-side
  e.g.,

  • Filters that involve computed fields (like discounts or margin %)

  • Nested field matching, where native Bubble search is limited

  • Dynamic comparison logic (e.g., user-defined operators like “merged with”, “contains”)

• You're building a “multi-step” filter UX with visible stages, where each filter step refines the next (hence the chain)

These are areas where chaining filters through custom states and conditional events gives you granular control and better perceived performance, as long as you’re aware of the memory and security costs.

Final Thought

I’m not claiming DCF is better than server-side filtering - I’m saying it’s different.
Used intentionally, it's a specialized tool, not a default pattern.

And the article I wrote here breaks down where the tipping point lies - when DCF becomes faster, and when it becomes dangerous.

TL;DR:

Let your admins log in as any user in Bubble.io — no passwords, no backend workflows.

Just:

1. Generate a magic login link (without emailing it),

2. Grab the link using a Toolbox Server Script, and

3. Instantly redirect the admin to log in as that user.

Perfect for support, QA, and testing — all in 3 simple steps.

🧐 Use Case

Let’s say your APP admin wants to see what a specific user sees in their account. Instead of asking for login credentials, you provide a “Run as” button next to every user in your Admin panel.

With one click, your app logs the admin in as that user and redirects them to the user’s dashboard.

✅ Requirements

• Bubble app with user roles (admin/user)

• Toolbox Plugin

• Admin Panel, which only the Admin can access

🚀 Step-by-Step: Implement “Run as User” in Bubble

✅ Step 1: Add “Run as” Button in Admin Panel User list

✅ Step 2: Set up the Magic link workflow on button click

Make sure to just create a token and not send an email. Here is what it will look like

⚠️ This sends a login link to the backend. It won’t send an actual email and you're just using the generated login link internally.

✅ Step 3: Use Server Script (Toolbox)

Add a "Server Script" action from the Toolbox plugin right after the magic link action.

In the script box, extract the login link like this:

let link = "Result of step 1 (Send magic login link)";
link;

Make sure to set the return type as text.

✅ Step 4: Redirect Using “Open External Website”

Add a final workflow step:

• Action: Open an external website

• URL: Result of Step 2 (Server Script)

This step instantly redirects the admin to the magic login link, logging them in as the selected user!

With this, the admin user will be logged out, and the admin will be signed in as a user to whose email was used in to create the magic link.

🔐 Security Best Practices

• ✅ Only show the “Run as” button to users with the Admin role.

• ✅ Add privacy rules to restrict access.

• ✅ Log impersonation actions (optional but good for audit trail).

🧩 Final Outcome

Your admin can now:

• Click “Run as” on any user

• Instantly be redirected to the app, logged in as that user

• Provide support, test behavior, or troubleshoot without credentials

❓ FAQ

What is the “Run as User” feature in Bubble.io?

It’s a functionality that allows admins to log in as any user in the app without knowing their credentials. It’s useful for support, debugging, and user experience testing.

Is it secure to log in as a user without a password?

Yes, if implemented properly. The magic login link is time-bound and only accessible to admins. Ensure your workflows are protected with role-based privacy rules.

Does the user receive an email when I use “Send magic login link”?

No. While Bubble's action generates a login link, it only sends an email if explicitly configured. In this case, the link is used internally and not emailed.

Do I need backend workflows to implement this?

No. This method uses only front-end workflows and the Toolbox plugin, making it easier and faster to set up.

Can I choose which page the admin lands on after impersonation?

Yes. The “Send magic login link” action allows you to define a redirect URL. You can set this to any page (like dashboard, settings, etc.).

Will the actual user be logged out when I log in as them?

No. This creates a new session for the admin. The original user remains unaffected and logged in on their own device.

How long is the login token valid?

You can set the token expiration manually in the “Send magic login link” action, usually anywhere from 1 minute to 24 hours.

🔹 TL;DR: You can self-host n8n on Hostinger in just a few clicks - no terminal, no Docker, and no code. This beginner-friendly guide walks you through setting up a VPS, installing n8n, and activating a free license. Perfect for non-techies, automation geeks, and anyone tired of cloud pricing.

In this guide, I’ll show you how to self-host n8n on Hostinger in just a few minutes. No terminal. No SSH. No Docker CLI. No YAML. Just simple steps - perfect for non-techies, automation geeks, or anyone tired of Cloud pricing.

🛑 But Isn’t Self-Hosting Hard?

Normally, yes, for people who don’t know how to set up a server. Most tutorials tell you to:

• Spin up a VPS

• Install Docker via the terminal

• Run docker-compose

• Configure environment variables manually

• Pray nothing breaks

But if you're using Hostinger, there’s a shortcut. You can deploy n8n using Hostinger's App Installer and a few clicks.

Let me walk you through it.

Step 1: Log in to your Hostinger account

Go to https://auth.hostinger.com/in/login and provide your information.

Step 2: Set up VPS

Go to the VPS section and choose KVM VPS

Select server location: For me, it’s INDIA. You can choose your nearest server location

Now search for n8n in the operating system

Now, set up the root password

Now choose a plan. If Hostinger is providing price parity for your location, opt for it. I think KVM 2 is good enough.

Once you select the plan and complete the payment, the n8n hosting will be initiated automatically.

Once the setup is completed, you can go to manage the VPS

Step 3: Manage VPS

On Dashboard → VPS → Click on Manage app

Now you can set up an owner account

After setting up the owner account, Hostinger is currently providing some lifetime free features. Just enter your email ID and receive the license key within minutes.

Now go to usage and plan to activate the license using the license key received in your email.

After this, you can sign up with your owner credentials and start using n8n on your self-hosted server.

You don’t need to be a developer to self-host n8n anymore. Tools like Hostinger have made it a click-and-go easy.

Whether you’re automating lead generation, connecting Airtable and Gmail, or syncing your Notion database, n8n can handle it.

And now you can host it yourself - no terminal required.

To support more articles, buy me a coffee

❓ FAQs

Can I self-host n8n without Docker or terminal access?

Yes! Hostinger’s App Installer allows you to set up n8n on a VPS without using Docker, SSH, or any command-line tools.

Is there a free version of n8n when self-hosting?

Yes. Hostinger currently offers a lifetime license key for some advanced n8n features like workflow history, folder organization, and more - just enter your email during setup to claim it.

Who should use this self-hosting method?

This guide is ideal for non-techies, no-code builders, indie hackers, and automation enthusiasts who want to control their infrastructure without touching the terminal.

How long does it take to set up?

On average, it takes about 10–15 minutes to fully deploy and configure n8n using Hostinger.

Is Hostinger the only way to self-host n8n?

No, there are other ways (e.g., DigitalOcean, Railway, Docker CLI), but Hostinger offers one of the easiest no-code paths for beginners.

A common mistake developers make is thinking they’ve implemented pagination just because data is displayed page by page. But behind the scenes, Bubble still loads the entire dataset into the browser on page load. Suppose there are 1,000 records and your app shows 10 records per page. If a user only browses the first 3 pages, you still pay the WU cost for fetching all 1,000 records, not just the 30 that were actually viewed.

If your Bubble app feels slow or is using more workload units (WUs) than expected, the problem might be how you're handling data in repeating groups. Loading an entire list of items at once can slow down your app and increase your resource usage, especially when dealing with a large database.

In this article, you will learn how to paginate repeating groups in Bubble.io to load data in smaller chunks. This approach improves performance, reduces workload unit consumption, and creates a better experience for your users. Whether you're working on an MVP or scaling an existing application, these techniques will help you build smarter and more efficient apps.

Now I am considering that repeating group is ready and now you are implementing pagination. Here is the best practice to do that.

Step 1: Setup Hidden Variables

Create a popup named Popup Hidden variables and create following Groups shown in the image below:

Set all these group’s type of content as number.

Here is the data source for each group:

• Group Item_from - 1

• Group Total_count - Do a search for:count [Do a search for:Count will not load all data. If you inspect, you will find out in network tab → maggregate that this will return number only from server]

• Group Current_page - 1

• Group Item_until - 10

• Group Show_per_page - 10

Step 2: Setup UI for Pagination

After, The Show per page: is a dropdown which will static values like shown in the image below

Add Toolbox plugin (It’s free!) Here is the link.

Add List of Numbers element of toolbox plugin on the page and configure it as shown in the image below:

Between Prev and Next button there will be Repeating Group of page numbers which has List of numbers as data source shown below:

Setup View 1-50 of 2,500 results as per the image below:

With this, UI setup of Pagination Group is completed.

Step 3: Setup Repeating Group Source

Here I am loading Email templates in Repeating Group, so the data source setup will be as per shown in the image below:

Remember, Use :items until# before using :items from#. Here is the logic behind it given by bubble.io

Step 4: Setup Pagination Workflows

I don’t recommend using display data in repeating group action as in my experience, It is not good practice for performance! But it is ok to use display data in group as the number of item will always be one!

Create 2 custom events:

1. update-page:

   This event will update page number in Group Current_page as shown in the image below

   

2. update-list:

   This event will update from and until number in Group Item_from and Group Item_until as shown in the image below

   

   Here is the formula for data update of Group Item_from: [{( Current page number * Show per page number ) - Show per page number} + 1]

   Here is the formula for data update of Group Item_until: Current page number * Show per page number

Create Dropdown Show per page value change workflow event:

On the UI of pagination, there is the dropdown from where user can select how many entries per page user wants to see like 10 or 30 entries per page. User can change the value from the dropdown as we have seen in Step 2. Now when user changes the value of dropdown, this workflow will trigger as per shown in the image below

So here there are 3 actions:

• Display data in Group Show_per_page

• Trigger update-page

• Trigger update list

Create Page number click workflow event:

Page numbers are part of Repeating group List of numbers’ numbers so on click of this Repeating Group’s group, this workflow will trigger as per image shown below

This will set current page as whatever number user has clicked

Create Previous and Next button click workflow event:

And here your optimised performant Pagination Ready:

UX Suggestion:

To improve UX when User is clicking and Repeating Group is loading, you can add skeleton loading for better UX. Here is the article link about How to create Skeleton Loading in Bubble?

🔚 Conclusion

Pagination in Bubble.io isn’t just about showing fewer records per page — it’s about how the data is fetched and rendered. Most developers unknowingly fall into the trap of client-side pagination, where the entire dataset is loaded up front, leading to slow performance and unnecessary workload unit (WU) consumption.

By implementing true server-side pagination, as outlined in this article, you can dramatically reduce WUs, improve load times, and scale your app more efficiently. Using hidden variables, structured pagination logic, and smart workflows, your repeating groups will load only the data that’s actually needed — no more, no less.

If you care about performance, cost optimization, and creating a seamless user experience, building pagination the right way is a must. Apply this setup to your current and future projects, and you’ll see the difference in both speed and server costs.

A sub-app is a separate app instance created from your main Bubble app. It:

• It has its own database (you can optionally copy data from the main app at creation).

• Has its own domain, users, privacy rules, and media uploads.

Shares the editor design, workflows, and data types pushed from the main app.

What is the need for sub-apps in bubble.io?

Bubble.io sub-apps are not just copies of your app - they're a strong way to grow your product setup, provide custom deployments, and handle the needs of multi-client SaaS. Whether you're aiming for small businesses or large companies, sub-apps offer flexibility, security, and ease - all within Bubble’s no-code platform.

1. White-label SaaS: Give Each Client Their Own Branded App

One of the most common reasons to use sub-apps is to power white-labeled software.

🔧 Here is the problem sub-apps will solve:

If you offer your product to multiple businesses (e.g., gyms, schools, agencies), each might want its own logo, branding, domain, and client-specific features. Managing all of this in a single app instance can become chaotic and limit scalability.

✅ Solution with Sub-Apps:

• Create a sub-app for each client from the main Bubble app.

• Customize branding, themes, and domain per sub-app.

• Keep the core logic consistent across all clients by pushing updates from the main app.

Each client has a completely isolated database, increasing security and privacy.

2. Enterprise Deployments: One App Per Company

Larger enterprise clients often require full data separation, enhanced security, or compliance with internal policies (like SOC 2).

🔧 Here is the problem sub-apps will solve:

Enterprises may not want to share infrastructure with other users or want full control over data retention and access.

✅ Solution with Sub-Apps:

• Give each enterprise its own sub-app—technically a standalone Bubble app.

• Data is not shared across apps; only the data structure and editor updates are pushed.

• Enterprises can have their own deployment schedules, access policies, and even admin roles.

🛡️ This gives your product a multi-instance architecture without the engineering complexity you'd typically face building it from scratch.

3. Regional Versions: Comply with Local Laws and Optimize Performance

If your app operates across multiple countries or regions, you may need to comply with data localization laws or reduce latency by deploying closer to your users.

🔧 Here is the problem sub-apps will solve:

Running a single app globally might violate data policies like GDPR or create latency for users far from your app’s server location.

✅ Solution with Sub-Apps:

• Spin up sub-apps hosted on different domains or subdomains (e.g., app.company-eu.com, app.company-us.com).

• Keep data physically and logically separated by region.

• Customize privacy rules, legal content, or features based on locale.

🌍 Examples:

• A FinTech app with separate EU and US sub-apps for GDPR and CCPA compliance.

A learning platform with region-specific languages, currencies, and legal disclaimers.

How do you create a sub-app from the main app?

You need to upgrade your main bubble app on the Team Plan to have the ability to create a sub-app.

Once you are in Team Plan, you can create a sub-app from any branch by going to Settings → Sub apps → create a sub-app with the app name and DB Copy shown in the image below:

This newly created sub-app will be shown in your bubble.io account with the free plan.

• Important Notes:

  • All Team plan collaborators of the main app won’t be added to the sub-app collaborator.You need to upgrade your sub-app plan to the Growth plan to add more collaborators.

  • No matter which branch of the main app, you are creating a sub-app; the Sub-app will be a replica of the main branch version of the main app.

  • If you ‘remove’ a sub-app from the main app, it won’t be deleting an app. It will just break the connection between the main and sub-app. To delete the sub-app, you need to go to the app and delete it like you delete the regular bubble.io app.

• To save excessive cost, here is what I recommend

  - Give ownership of sub-apps related development to the single developer from your team- Create all sub-apps from that developer's bubble.io account

  - Upgrade that bubble.io sub-app to the starter plan. So the person who needs to work on sub-apps will be working on that with the starter plan.

  - If you need multiple developers working on a single sub-app, then there is no other choice but to upgrade to the Growth Plan to add multiple developers as collaborators in the sub-app. - Make sure you create your business model accordingly.

How to Push Updates to Sub-Apps from the main apps?

Here’s a step-by-step guide to safely push updates to sub-apps:

Step 1: Create a Dedicated Branch for Sub-App Changes (Recommended)

Before making changes intended for sub-apps:

• Go to the Branches tab in the Bubble editor.

• Create a new branch (for example: subapp-update-branch).

• Build and test your changes in this isolated branch.

This allows you to separate sub-app-specific changes from other development work.

Step 2: Merge That Branch into the main Branch

Once your updates are tested and ready:

• Merge your working branch into the main branch.

Only the main branch can push updates to sub-apps. No other branch has this ability.

Step 3: Push Changes from the Main App to Sub-Apps

Navigate to:

• Settings → Sub-Apps tab

• Locate the list of connected sub-apps

• Click “Push changes” for each sub-app you wish to update

This process will transfer:

• All editor changes (pages, workflows, logic)

• Data type structures (not data)

Step 4: Revert or Reset the Main Branch (Optional)

If your changes were only meant for sub-apps and not for your live app:

• Revert the main branch to its previous state, or

• Reset the main branch to the live version

This ensures the main The branch stays clean and doesn't accidentally deploy sub-app-specific changes to your production environment.

What will be copied from the main app to the sub-app, and what will remain independent in the sub-app?

What doesn’t Get Pushed from the Main app to the sub-app?

The following are not transferred to sub-apps during a push:

• Database records (live data)

• Media files (each sub-app manages its own)

• App settings, domain, and logs

• Plugin-specific configurations unique to each sub-app

Special request to bubble.io for specific sub-apps setup

You can request for specific settings to not propogate from main app to sub-app to Bubble team as per Bubble.io manual

Here is the screenshot of specific section:

The most important part to implement in existing sub-apps before pushing changes from the main app to sub-apps:

• Create a save point in existing sub-apps before the push.

• When you push to all sub-apps, it won’t raise any conflict with existing sub-app changes that you made separately, and will make all Editor (UI & workflows) and Data Types (structure) the same as the main-app, which you didn’t want for all sub-apps; you will be able to restore your created save point and figure out another way to implement some of the necessary changes from the main-app, but it will save your independent changes made in sub-apps.

Best Practices and Tips for Working with Sub-Apps in Bubble.io

Using sub-apps effectively requires not just knowing how to push updates, but also following a disciplined approach to avoid confusion, data issues, or deployment errors.

1. Use Clear Naming Conventions for Sub-Apps

As your number of your sub-apps grows, it’s easy to lose track of which sub-app is for which client, region, or use case.

Recommendation:

• Include the purpose or client name in the sub-app name, such as client-xyz-app, staging-eu, or demo-app-v2.

• Maintain a naming convention that clearly distinguishes between production, staging, and testing environments.

Why it matters:
It improves collaboration, simplifies documentation, and reduces the risk of pushing updates to the wrong sub-app.

2. Keep the Main App Clean — Use Branches for Development

The main app should only reflect the version you want all sub-apps to inherit. Avoid building or testing new features directly in the main branch.

Recommendation:

• Create dedicated branches for feature development or sub-app-specific changes.

• Merge only the final, stable version into main when you are ready to push to sub-apps.

Why it matters:
This minimizes the risk of deploying unstable code across all sub-apps and keeps your main app production-ready at all times.

3. Always Document What Was Pushed and Why

When you push changes to a sub-app, there’s no automated log that tracks what was updated or why. This can lead to confusion, especially in teams.

Recommendation:

• Maintain a change log (in Linear, Notion, Google Docs, Git-style README, etc.).

• Include: what was changed, which sub-app(s) were affected, and who made the push.

Why it matters:
It helps with debugging, accountability, team communication, and audit trails.

4. Backup Your Main App Before Major Pushes

Pushing updates to sub-apps is irreversible—you can’t “undo” a push once it’s done. If something breaks, recovery becomes harder.

Recommendation:

• Before pushing major changes to sub-apps, make a manual backup of your main app by duplicating it or exporting the app JSON.

• You can also use Bubble’s built-in version control to create save points.

Why it matters:
Having a backup gives you peace of mind and a fallback option in case something goes wrong during deployment.

Sub-apps in Bubble.io give you a clean, scalable way to serve different clients, regions, or testing environments - all while keeping your core logic centralized.

In this guide, we covered not just how to set up and push updates to sub-apps, but also best practices to avoid breaking your main app.

Whether you're building a white-label SaaS, serving enterprise clients, or working across global markets, sub-apps can save you time, reduce complexity, and improve data isolation.

Use branches, document your pushes, and back up before major changes, and you’ll be well on your way to building a stable, scalable no-code infrastructure.

Got questions? Ask in the comments. To support me, buy me a coffee.

Let’s say you’re displaying a list of Works, and each work has a related Work_satellite data type. Now, you want to sort your repeating group of Work by the Work_satellite’s last modified date.

This is where Bubble’s built-in sorting options hit a wall, because you can't directly sort a repeating group by a nested field like Work's Work_satellite's Modified date.

But don't worry. In this article, I’ll walk you through the step-by-step process to do it.

Step 1: Load the Repeating Group’s data in the pop-up

In this example, I am loading the data of work in a pop-up

Step 2: Install ‘Floppy: localStorage, List Shifter’ plugin

Step 3: Set up List Shifter as the data source of the Repeating Group of the page

Place the ‘List Shifter Pro’ element on the page and provide RG Work’s data as a List to shift shown in the image below

Now, place the ‘List Shifter’s shifted list’ as data source of the Repeating Group, which is on the page, and where you want to execute the sorting by field’s field, or in our case Work's Work_satellite's Modified date

Step 4: Set up a workflow for sorting by the field’s field or the Nested field

You can either do the sorting by default when the Repeating Group is visible on page load, or you can execute the sorting when the user selects it via a dropdown or some other way.

I am setting this up as a custom event, which you can trigger on page load or when the user selects this nested field’s sorting.

I have created a custom event named ‘sort-list’ and added the action from the List Shifter plugin named ‘Sort List a List Shifter Pro

As you can see in the image above**, I want to sort the RG data via modified data of nested field, that is why I have selected ‘sort as’ and ‘type of sort by list’ as date.

In the ‘sort by List’, I have selected RG Work’s List of Work’ each item’s work_satellite’s modified date. Here, RG Work is the repeating group from the popup, not from an on-page repeating group.**

Step 5: Show the Repeating Group after nested sorting is completed

There is an event from the List Shifter plugin named ‘ListShifterPRO WorkListShifterPRO Sort Complete’ that will be triggered once the custom event of sorting is executed and sorting is completed. On completion, you can now show on the page the Repeating Group with sorting by Work's Work_satellite's Modified date

This is how you sort a repeating group in Bubble.io by a nested field. If you find this article helpful, you can buy me a coffee and show your support and appreciation.

Here are some important terminology:

What is an AI Assistant?

An OpenAI Assistant is a tool that uses AI to have conversations. It's built with advanced language models like OpenAI’s GPT, which can understand and create natural language responses. You can add it to websites, apps, or platforms to do things like answer customer questions, create content, help with learning, increase productivity, and provide entertainment. In Bubble.io, an OpenAI Assistant can improve apps by adding features like automatic replies, personalized suggestions, and task automation, giving users a smooth and smart experience.

Here is the setup:

Step 1: Log in to Open AI and create an assistant

Create an open AI account on https://platform.openai.com/playground/complete

On Playground, Create a new assistant with system instructions. For example, Here I am creating a travel assistant which you can see in the image below:

On assistant creation, the assistant ID will be automatically generated by bubble.io which we will use later.

Step 2: Generate Secret API Token/Key in Open AI

Go to: https://platform.openai.com/settings/organization/api-keys
Create a new API key there by clicking the button shown in the next picture

Step 3: Setup API Secret key in Bubble

Now go to api connector in your bubble.io app and set the Open AI secret key in the Header for all open AI calls.

What does the Private key in the Header mean in the bubble.io api connector?

This method involves adding the key to the header of all requests, usually under the parameter name Authorization, though you can use a custom name as specified in the external API documentation if necessary.

Below image and explanation of the image were taken from the bubble.io manual.

1. The first is the name of the parameter the server needs.

2. The second is the actual API key for the development version of your app.

3. The third is the API key for the live version of your app.

What does a private key in the header look like?

Authorization: Bearer <token>

The example above would be one row of the header – it also contains other data. The <token> is replaced by the actual token without the <> signs just like in our example below

What are shared headers for api calls?

In Bubble.io, the "shared header" in the API Connector lets you set common HTTP headers that will be automatically added to all API requests made through a specific API connection. This is helpful for headers like authentication tokens, API keys, or content-type specifications needed for every API request.

How an API Call with Shared Headers Works:

1. Shared Headers: Headers set in the shared header section are included in every HTTP request for all API calls using that connection.

2. Endpoint-Specific Headers: You can add custom headers for individual API calls or endpoints, which will be combined with the shared headers.

3. Complete API Request: When you make an API request, Bubble combines the shared headers with any endpoint-specific headers you add. The request is then sent with all necessary headers.

This setup ensures your API calls are consistent and reduces the need to repeatedly define headers, making API integration easier.

Step 4: Understand How the AI Assistant will work via API

Here is the flowchart of the whole process:

We have already created an assistant in step 1 that provided us assistant ID.

• Save the assistant ID in the database for us to use in API Calls

• Creating a Communication Thread: With the assistant ready and its ID safely stored, it's time to create a thread for organizing interactions. Think of this thread as a conversation space where all messages between the user and the assistant are contained, making it easier to track and manage communications.

• Creating a Message: Within the newly created thread, you can now create a message as a user for the assistant. Basically whatever users write to AI will be created as a message. Understand this, creating a message and sending a message to AI are both different things. Right now, we have just created a message, and haven’t sent it to AI yet.

• Creating a Run: To process the message, a "run" is created. This involves executing any tasks or computations necessary to respond to the user. The run is essentially the action engine, driving the assistant's functionality. In easy language, when the run is created means we have sent a message to AI and now AI is processing it.

• Monitoring the Run Status: Once the run is initiated, it's crucial to monitor its progress. This involves retrieving the run and checking the current status of the run and whether the run has been completed. If it’s still in progress, our bubble.io app will continue to check the status until completion.

• Retrieving All Messages: Upon successful completion of the run, the final step is to retrieve all messages within the thread. Once we receive the messages, we will show those messages to the user and then the user can create more messages to interact with an assistant if the user wants.

Step 5: API Setup in Bubble

Assistant is created in open AI and we have to get the assistant ID from there.

Now Let’s set the following APIs in API Connector

• Create Thread

API Documentation: https://platform.openai.com/docs/api-reference/threads/createThread
The Bubble.io API Connector setup is shown in the image below

From a successful API response, you will get a thread ID, Save it somewhere because we will need it in other API calls.

• Create a Message

API Documentation: https://platform.openai.com/docs/api-reference/messages/createMessage

The thread ID we saved earlier will be used here.

The Bubble.io API Connector setup is shown in the image below

• Create Run

API Documentation: https://platform.openai.com/docs/api-reference/runs/createRun

The thread ID and assistant ID we saved earlier will be used here.

The Bubble.io API Connector setup is shown in the image below

Now from the successful API Call, Save the Run ID.

• Retrieve Run

API Documentation: https://platform.openai.com/docs/api-reference/runs/getRun

The thread ID and run ID we saved earlier will be used here.

The Bubble.io API Connector setup is shown in the image below

• List Message

API Documentation: https://platform.openai.com/docs/api-reference/messages/listMessages

The thread ID we saved earlier will be used here.

The Bubble.io API Connector setup is shown in the image below

With this, all the essential APIs are set in bubble.io

Step 6: Make Open AI API Calls More Secure in a bubble.io

Even if your run ID, assistant ID, and thread ID are public. They are useless without an Open AI secret key which we are not exposing here in all API calls. The secret key is set as a private key in the header so your api calls are secure.
To make your api calls more secure, check this: Bubble.io API Call Security Best Practices

Step 7: UI Setup in Bubble

• Prepared a basic setup with the Start button shown below

• Some loading for UX when APIs are in execution

Create a chat Interface with multiline input to write a message, make sure we can with UI we can identify responses from the user and assistant.

UI creation conceptualization was assisted by Dixit Patel

Step 8: Workflow Setup in Bubble

• Create an option set to track run status with three options: Not Running, In Progress, Completed

  • not running is a default status

    

• Create custom states on the page level that store: thread ID, run ID, run status, and list of messages (List Messages API data type)

  

• Add a simple looper plugin from here

On the Start button (Shown in UI) run the following workflows

Then,

• Once the loop is finished, here is what happens

  

• Then load all the messages into a custom state or database (your choice)

  

Till now, you have seen the workflow execution from the start button. Now if this is executed from multiline input of chat, then the workflow will be similar with some minor changes (shown in the image below)

Step 9: Differntiate User and Assistant Messages

Now Just show the messages in chat UI created either via custom state or via database.

In my example, I have shown messages in Repeating Group Chat which I set like this:

To identify the messages from the User and assistant, you can use roles to differentiate

These step-by-step instructions cover everything from setting up your OpenAI account and generating API keys to configuring API calls and designing a user-friendly interface. By following these steps, you can create a sophisticated AI assistant that elevates your app's functionality and user experience, paving the way for innovation and efficiency in your projects.

Bubble.io’s default scrollbar doesn’t give the desired UI/UX your app needs. Rather than using any plugins, you can write code to achieve the scrollbar style you would like.

You can use this code in multiple places depending on your use cases.

• To apply the scrollbar styling to the whole app: Go to settings → SEO/metatags → Script in Body from your bubble.io editor and write the code mentioned below.

  

• To apply the scrollbar styling on the whole page level: Go to Page on bubble.io editor, open page properties, and write the code mentioned below on Page HTML Header

  

  Here is the code that you can copy directly and paste into your app.

<style>
/* Customize the scrollbar */
::-webkit-scrollbar {
  width: 2px; /* Width of the scrollbar, you can modify the number */
}

::-webkit-scrollbar-thumb {
  background: #000000; /* Scrollbar thumb color, you can modify the color hex code */
  border-radius: 5px; /* Rounded edges for the thumb, you can modify the number */
}

::-webkit-scrollbar-thumb:hover {
  background: #FFFFFF; /* Thumb color on hover,you can modify the color hex code */
}

::-webkit-scrollbar-track {
  background: #FFFFFF; /* Scrollbar track color,you can modify the color hex code */
  border-radius: 5px; /* Rounded edges for the track,you can modify the number */
}


</style>

• Now If you want to modify the styling of the Repeating Group Scrollbar or the scrollbar of specific components on the page, Here is the code

    <style>
    /* Customize the scrollbar for the Repeating Group */
    #custom-scrollbar ::-webkit-scrollbar {
      width: 2px; /* Width of the scrollbar */
    }
  
    #custom-scrollbar ::-webkit-scrollbar-thumb {
      background: #000000; /* Scrollbar thumb color */
      border-radius: 5px; /* Rounded edges for the thumb */
    }
  
    #custom-scrollbar ::-webkit-scrollbar-thumb:hover {
      background: #FFFFFF; /* Thumb color on hover */
    }
  
    #custom-scrollbar ::-webkit-scrollbar-track {
      background: #FFFFFF; /* Scrollbar track color */
      border-radius: 5px; /* Rounded edges for the track */
    }
    </style>
  

  Enable the ID Attribute option in your app settings:

  • Go to Settings > General.

  • Check the box for Expose the option to add an ID attribute to HTML elements.

  • Now Add an HTML element to the page and paste the modified code into the HTML element.

  • In the Repeating Group's properties, assign the ID attribute as custom-scrollbar

How to Create a Custom Picture Uploader or File Uploader in Bubble.io? (No Paid Plugins)

There are many style limitations for picture uploaders and file uploaders in bubble.io. So you would like to design a custom uploader using groups, icons, and text elements as per your requirements but on clicking that custom uploader, it should work the same as if a user is clicking on picture Uploader or file uploader.

For example, here is the custom uploader I designed using group, text, and icon elements:

But on the element level, there is a tiny picture uploader inside:

Now On clicking on the group certificate image, I want the UX to be the same as if the user is clicking on the picture uploader. Here is how to achieve this:

• Install the Toolbox plugin in the bubble.io app

• On click of Group Certificate Image, set the ‘Run Javascript’ action with the following code

    document.getElementById("education").getElementsByTagName("input")[0].click();
  

• Place the ID Attribute ‘education’ on the element that you would like to simulate on click, in our case, it is the picture uploader

  

  So clicking on the group will work as if the user has clicked on the picture uploader.

How to prevent page scrolling when popup is visible in bubble.io? (No Paid Plugins)

Here are the reasons why this is necessary:

• Problem: If the user scrolls while the popup is open, the background content moves, which can be distracting. In Bubble, the popup might stay in place while the background moves, causing visual issues like misaligned elements. Scrollable backgrounds can confuse users using keyboards or screen readers, as they might interact with the wrong elements. If the page scrolls behind a popup, it can mess up the layout, especially for apps with parallax effects or sticky elements. Users might accidentally click or interact with background elements while scrolling, leading to unintended actions.

• Solution: Disabling scrolling ensures the background remains static, keeps the user focused on the popup's content, prevents design inconsistencies, and avoids unintended interactions.

Here is how to achieve this:

• Install Toolbox Plugin

• Create a ‘Do when condition is true’ workflow and Put condition that this will trigger everytime when the popup is visible.

• On trigger of this workflow, set the ‘Run Javascript’ action with the following code.

• Place the ID Attribute ‘experience’ on the popup

  With this, Scrolling is disabled for the background but enabled for the popup content if it overflows the given height.

// This is every time the popup is visible

  $("#experience").wrap( "<div class='innerScroll'></div>" );

  $(".innerScroll").css({'overflow-y':'auto','position':'fixed','top':'0', 'left':'0', 'right':'0','bottom':'0','z-index':'10000'});

  $("body").css('overflow','hidden');

  var esc = $.Event("keydown", { keyCode: 27 });

  $(".innerScroll").click(function(){
    $("body").trigger(esc);
  });

• Create a ‘Do when condition is true’ workflow and Put condition that this will trigger everytime when the popup is not visible.

• On trigger of this workflow, set the ‘Run Javascript’ action with the following code.

With this Scrolling on the page (background content of popup) is re-enabled, returning the page to its normal state.

//   This is every time the popup is not visible

  $("#experience").unwrap();

  $("body").css('overflow','auto');

How to Adjust Page Height based on Header Size in bubble.io? (No Plugins)

Adjusting the page height based on the header size is important for creating a clean and professional layout. This ensures that your content dynamically adjusts to fit the available space, without being hidden behind or overlapping the header.

For example:

• On a page with a fixed header, you want the content area to fill the remaining screen space.

• As the header's height might vary based on screen size or dynamic content, it’s important to account for these variations.

The header can be a fixed or floating group, depending on your design.

• Add an HTML Element to your page where you want to insert the CSS.

• Inside the HTML element, paste the following CSS code:

<style>
#pageheight {
    min-height: calc(100vh - 60px) !important; /* Adjust '60px' with your header's height dynamically */
}
</style>

Here 100vh is the total viewport height (100% of the screen height).

set the ID pageheight of your Parent Groups other than the Header that needs to be adjusted based on the header.

How to Create Full-Height Sections in Bubble.io for a Responsive Layout? (No Plugins)

Creating sections that fill the entire screen height is a common requirement, especially for landing pages, hero sections, or single-page layouts. In Bubble.io, you might want to ensure that certain elements always take up at least the full height of the viewport, no matter how much content they contain.

1. In the Bubble.io editor, go to the page where your section is located.

2. Drag and drop an HTML Element onto your page.

3. In the HTML Element, insert the following CSS code:

<style>
#viewport {
    min-height: 100vh !important;
}
</style>

Here 100vh is the total viewport height (100% of the screen height).

you need to apply the viewport ID to the group you want to stretch.

1. Select the Group element (the one you want to be full height) in the Bubble.io editor.

2. In the Property Editor for the group, look for the ID Attribute field.

3. Set the ID to viewport.

In conclusion, mastering customization in Bubble.io can significantly enhance the user experience and interface of your applications. By leveraging custom code for scrollbars, uploaders, popups, and responsive layouts, you can create a more polished and professional look without relying heavily on plugins. These techniques not only improve the aesthetic appeal but also ensure functionality across various devices and screen sizes. As you continue to explore and implement these strategies, you'll find that Bubble.io offers a flexible platform for bringing your app design visions to life.

Typography plays a crucial role in application development, influencing an app's user interface and user experience.

While bubble.io provides many font options, sometimes your project needs a specific style not found in their library. Custom fonts allow you to stay on-brand with unique typography, create a visually distinct experience, and meet client specifications if you're working on a branded project.

Here is the step-by-step guide on how to add custom fonts:

Step 1: Download the font file

For this article, I am going to use a custom font named ‘Taylor Sans’ which is not part of the bubble.io editor. It has an ‘OFL (SIL Open Font License’ so I can use it here in this blog freely.

I have downloaded this font from here. This font family has 6 font files with different font weights. Here are the 6 font file names:

• TaylorSans-Bold - 700

• TaylorSans-ExtraBold - 800

• TaylorSans-Light - 300

• TaylorSans-Regular - 400

• TaylorSans-SemiBold - 600

• TaylorSans-Thin - 100

  For this font family, you need to set up each font file independently. Here in this article, I will upload only one file ‘TaylorSans-Bold.ttf’. You can replicate the same for other files.

Step 2: Upload the font file

All the font files will have the ‘.ttf’ extension so I will call it a ttf font file. Now open the bubble editor and place the file editor element on the dummy/test page.

Upload the ‘TaylorSans-Bold.ttf‘ file as a static file and copy the link generated in the dynamic link section once the file is uploaded.

Step 3: Create a CSS script I have mentioned below on Notepad

Copy the CSS I mentioned below and paste it on Notepad. I am using an online notepad for this article.

@font-face {
font-family: 'Font-title';
src: url('file-upoader-url');
}

After pasting the CSS script on Notepad, change the Font-tile (In this case, it will be ‘TaylorSans-Bold’) and use the saved URL from step 2 which you got after uploading the .ttfl file

In the URL, add ‘https:’ before // and the CSS script in Notepad will look like the image provided below:

Step 5: Download the CSS font file

From Notepad, save this file and make sure to give the file name the same as font-title and give it a .css extension at the end.

When you save it, it will be saved in the device as a ‘TaylorSans-Bold.css.txt’ file. Rename this file in your device as ‘TaylorSans-Bold.css’. Remove .txt from the file name.

Step 6: Upload the CSS font file

Now let’s come to the editor again and upload this .css file on file-uploader. Once uploaded, save the URL of css file as well.

Step 7: Add CSS Path in the bubble.io

Go to Settings → General → Custom fonts

Here make sure that the Font name value is the same as the font title, In our case it will be ‘TaylorSans-Bold’. Add CSS file path as URL saved in step 6 and add ‘https:’ before ‘//’ so it will look like the image below:

Now click on Add Font and give it some time to load. It will look like the image below after added.

Step 8: Test the font in the application bubble.io editor

Add a text element in the editor and check the font where you will find ‘TaylorSans-Bold’ as an option for the text element.

Follow the same steps for all the files of font-family.

This is how you add custom fonts with just a URL link and a few settings, you can elevate your app’s design to a whole new level. It’s fun, right? 😉

Let me explain the problem here:

• In Bubble.io, a privacy rule like "This thing's salesforce is the current user's salesforce" can be risky if the "salesforce" field is empty for both the item and the user. When both are empty, the condition is seen as true, allowing access to data that should be private. This can accidentally expose data (like access_token, refresh_token, etc.) for the entire data table because the rule doesn't differentiate between matching specific values and matching due to being empty.

Here's how to fix it:

• Improve the privacy rule by adding another condition: "This thing's salesforce is the current user's salesforce AND the current user's salesforce is not empty." or "This thing's salesforce is another thing's salesforce AND another thing's salesforce is not empty."

Why does this solve the problem?

• By adding "current user's salesforce is not empty," the rule only allows matches when both fields are filled, stopping empty fields from matching by mistake.

This change stops data leaks by making sure only users with a valid, non-empty entry can see the data, keeping privacy intact.

2.Initialized API calls have unnecessary data

Plenty of times, I am unaware of which data from API responses I will need so I initialize the call and save all the responses. The time I am clear which data I need and which I don’t do the following in this special case.

In the image below, you can see I have successfully initialized the API Call and it is showing me all the data I am getting in my API call like access_token, signature, scope, instance_url, id, token_type, and issued_at.

But from this, I need only access_token. So in this successful API call, I can tell bubble to only accept access_token. It doesn’t make sense to receive all data when you need only a few So ignore the fields you don’t need as shown in the image below. The basic idea is to only have the data that the app needs to function properly.

3. Same authentication for every API Call

If the following conditions are met,

• There are multiple API Calls in a single API in a bubble.io API Connector

• 

• The same Private key/authentication token is being used for all the calls separately in their respective API Calls

• The Private key/authentication token is static

Then Use the Private key in the Header and provide the same private key for all the headers in a single place.
If there are static parameters (header parameters/body parameters) common for all API calls you can define them in Shared headers for all calls and Shared parameters for all calls.

4. Don’t use HTTP Endpoints

Many times, I discovered that API initialization showed an error about missing SSL, so I changed the endpoint from HTTPS to HTTP, and it worked. This is a warning sign.

Always make sure your API calls use HTTPS to protect your data from being intercepted by unauthorized parties. Check that the API base URL starts with https:// in the API connector settings. Doing this ensures your application only interacts with APIs that support secure connections, which is important for keeping the data private and intact. Additionally, using HTTPS helps prevent security risks that could occur from using insecure HTTP connections, protecting both your application and its users.

5.Use the principle of least privilege (PoLP)

Definition: The principle of least privilege (PoLP) is an information security concept that states users and applications should only have access to the data and operations necessary to perform their tasks.

In which areas this principle is applicable when working with APIs in bubble.io?

• Limit the Scope of API Access: Only add the permissions you need right now. Add more later if necessary.

• Limit API Key Permissions: For example, in Stripe, create restricted keys that can only do specific tasks, like creating charges but not processing refunds.

• Minimize Data in the API Request Body: See Tip 2 for more details.

• Role-Based API Workflows: Allow only admin roles to perform sensitive API tasks, like managing users or handling financial transactions. Restrict basic users or customers to actions that only retrieve information, such as viewing data without updating or deleting it. Use conditional logic in Bubble to stop unauthorized roles from triggering certain API workflows.

• Limit Developer Access: Only allow Live branch data access to certain developers who need it.

Learn the best practices for Bubble.io API Security here & Don’t forget to sponsor me a cup of coffee 😉

• Exposing sensitive information, such as passwords and tokens, because of unencrypted data transfers and visible API keys in logs.

• Unauthorized access and token theft.

• Risk service disruptions, account takeovers, and potential compliance issues.

• It opens the door to injection attacks and data leaks.

In the previous article, I have shown how to set API calls and OAuth in bubble.io using the bubble api connector.
A successful API call might look like in the images shown below:

OR

These API calls are not secure. Let me explain how.

• This API call, endpoint URL, and all its tokens (Client ID, Client Secret, Authentication token, refresh token, etc.) are visible on the developer console on each page load of the bubble.io application. It doesn't matter if I am using this API call or not. It will be visible to logged-out users (Unauthorised users) as well on any page load.

Best Practices for implementing secure API calls

Here are some of the best practices for implementing secure API calls and token management:

Step 1: Conceal API URL Endpoint

Now you must be wondering why should I hide my API URL Endpoint. Here is why:

• Exposing the endpoint could let malicious users access the API directly, understand my application's structure, and possibly exploit vulnerabilities. It also helps protect the privacy of my business logic and interactions with third-party services, maintaining both security and a competitive edge. Keeping the endpoint hidden adds an important layer of security to my application.

After understanding why, let’s dive into how.

As you can see in the screenshot attached below, I have divided the endpoint URL: https://login.salesforce.com/services/oauth2/token into 2 parts and put them in square bracket [url]/[endpoint]

Then I have defined url=https://login.salesforce.com/services/oauth2 and endpoint=token

Step 2: Safeguard Static Parameters

When making an API call, certain parameters remain constant, regardless of whether the call is a Data call or an Action call. These are known as static parameters. It is crucial to ensure that all these static parameters are kept private. By doing so, you protect sensitive information from being exposed or accessed by unauthorized users. This will prevent them from being visible on the client side through the developer console. Checkout the screenshot below:

On the Bubble.io app page load, the browser downloads all api calls on the user’s device, and if you don’t keep the static parameters like client_id, and client_secret private; anyone can access these parameter values on their device using the console.

Step 3: Manage Dynamic Parameters Securely

What are the dynamic parameters in API calls?

• When making an API call, some parameters may change based on specific inputs or conditions at the time of the call. These are called dynamic parameters. Unlike static parameters, which stay the same whether it's a Data call or an Action call, dynamic parameters are flexible. They can be updated with values that are generated or provided during each API request. This flexibility allows the API call to adapt to different situations or user inputs as needed.

Let’s understand how to make them secure.

Once I initialize the API call, I will remove all the parameters from the API connector that are not private. On the Above image of step 2, you can see that refresh_token is not private and because of that, it will still be visible on the developer console on every page load. Check out the below image:

This is still risky so remove it from here and because it is a dynamic parameter that varies from user to user, I will store all the dynamic parameters in the database. Check the screenshot below:

Step 4: Implement Privacy Rules for Dynamic Data

As shown in the screenshot above of step 3, the refresh token is a dynamic parameter that I did not make private. It is stored in the database as a field in a certain data type.

Without privacy rules, data is basically open to anyone using the app. Any user can possibly access the database data for that specific type. This includes data from things like repeating groups, text elements, and API requests. Any workflows that create, change, or show data that can lead to unauthorized changes or exposure of data.

So here I have defined privacy rules that will accomplish the following:

• Do not show the refresh token, access token, and access token expiry date to any users who are logged out.

• When a user is logged in, the application will allow access only to their own refresh token, access token, and access token expiry date. Users will not be able to see anyone else's refresh token, access token, or access token expiry date.

Checkout the image below to check the privacy rules setup:

Step 5: Replace Initialised API Call Response with placeholders

Let’s understand how bubble.io works:

• When I set up an API call in Bubble.io, the API Connector plugin automatically makes a test call to understand how the API response is structured. This process creates a response schema - a template that represents the format and structure of the data the API returns. This schema helps Bubble understand what kind of data to expect when the API call is made in real-time.

• After the initial test call, the response schema is stored in my app's configuration, specifically in a file called app.json. This file is part of my app's settings and can be accessed by others if it's not secured properly. Therefore, if the test API call includes sensitive information - like access tokens, API keys, user data, or app IDs - this information will be saved as part of the schema.

Issue: If I don’t clean up these sensitive details before deploying my app, they might become visible to anyone who can access the app.json file or inspect the API response structure.

Solution:

• As you can see in the image shown below, my initialized api call contains actual sensitive information that will be visible on the developer console and if it is leaked, my account, my credits, my data, etc can be misused.

  

• Now, when you save it, you will know the exact type (like text, number, yes/no, file, image) of the data each field contains. check the image below for more clarity.

  

• The reason for the bubble.io to save it is just to understand data structure whenever an API call is made that means, in manual response if there is ‘access_token’ and the type of field is text then I don’t need actual access_token but some arbitrary text which will let api response to identify as text.

• So I will replace the existing original data with a placeholder for the same type of data

  

Following these steps, your app's response schema will contain placeholders instead of sensitive data. When you deploy your application, any potential exposure of sensitive information will be avoided. This practice enhances the security of your app, especially when dealing with data like access tokens, API keys, and user information.

Step 6: Limit Developers' Access to Dynamic Tokens

Now, developers working with applications and having access to the Bubble.io app editor can also access the data. However, not every developer needs to see this information. Bubble.io offers a way to restrict developer access to data as well.

Go to Setting → Collaboration and restrict the data access for developers who don’t need it.

For Data, there will be 4 options explained below:

• No permission - (cannot see or edit any database data in Development or Live)

• View only - (can view data but cannot change it in the database editor)

• View and run as - (can view data and use the run as feature)

• View and edit - (can view and freely edit data)

How did I secure API Calls & tokens till now?

• With Step 1, I ensure that no user can identify the API calls the app is making, regardless of their login status.

• With Step 2, static parameters like the client ID and client secret are completely inaccessible in the developer console for all users, whether logged in or out.

• With Step 3, dynamic parameters are hidden for all users (authorized/unauthorized) in the developer console of the browser on page load.

• With Step 4, dynamic parameters are hidden from logged-out users, and logged-in users are restricted from accessing tokens of other users.

• With Step 5, Anyone (authorized/unauthorized) won’t be able to find actual data in bubble.io’s saved API response because I have replaced it with placeholders.

• With Step 6, developers who don't need to view or edit data are denied access.

This is how I recommend securing API calls and tokens from any user, logged-out users, logged-in users, and unauthorized developers.

Special Cases & Your API Practices

Tell me, how you are setting up your APIs in bubble.io currently? & buy me a coffee 😉. Also If you would like to learn about some special cases tips for API Security, click here.

Yes! Deleted pages do consumer workload units. To understand why they consume it and how to effectively prevent them, Let’s understand the type of deleted pages.

2 categories of deleted pages in Bubble.io

There are 2 kinds of deleted pages in the bubble.

1. Pages you created and then deleted from the editor manually.

2. Deleted but not created by you are default pages automatically set up by Bubble, such as the index and 404 pages.

Why do these deleted pages consume workload units?

• Manually deleted pages by you can consume workload units if they had workflows attached to them that were not properly removed before deletion. This can happen because the system continues recognizing the workflows until they are explicitly removed or the associated elements are deleted. If you have deleted pages and notice unexpected workload consumption, it may be due to these lingering workflows.

• Default pages set up by bubble and not manually created by you are necessary. for example, The 404 page specifically displays an error when someone attempts to access a non-existent page.

  So, if you come across deleted pages you didn't create, they are likely the default ones by bubble and when they load, they consume workload units.

How to stop these deleted pages from consuming workload units (WU)?

• To optimize your Bubble application when dealing with default pages that have been deleted but not created by you or pages that were created and deleted by you, consider the following steps:

  1. Make sure all workflows are correctly deleted before removing pages or elements in the future. It's crucial to understand that once these deleted elements are no longer in the system, they will no longer consume workload units.

  2. Upgrade to the latest Bubble version to benefit from recent performance improvements.

  3. Uninstall any plugins that are not actively used in your application.

  4. Remove broken links from internal application navigation which leads to the loading of 404 pages.

  5. Utilize the 'clean app/app optimization' tool in Settings > General to help streamline your app's performance.

     

Implementing this will not just only reduce unnecessary workload unit consumption but will improve the performance of your application as well.

Help me!

If you enjoyed this post and found it helpful, Kindly consider supporting my work by buying me a coffee! Your support helps me create more valuable content and continue sharing useful resources. Thank you!

The Dunning–Kruger effect is a cognitive bias in which people with limited competence in a particular domain overestimate their abilities. It was first described by Justin Kruger and David Dunning in 1999.

It can affect anyone, but it's more likely to happen to people who lack knowledge or skills, are overconfident, or are poor performers. The Dunning-Kruger effect can also affect people who excel in a given area. These people may underestimate their abilities because they think the task is simple for everyone.

The Dunning-Kruger Effect in No-Code Development

At first, the no-code landscape feels like an exciting world of possibilities. With a few clicks and drag-and-drop functionalities, you can create a working prototype in no time. For beginners, this immediate success may lead to overconfidence. After all, if you’ve built a functioning app in days, how hard could the rest of it be?

Here’s where the Dunning-Kruger Effect comes into play. The initial ease of creating something tangible can lead to the belief that no-code programming is far simpler than it actually is. This false sense of mastery often leads to a harsh reality check when more complex tasks—like optimizing performance, integrating APIs, or solving bugs—require deeper knowledge and problem-solving skills.

The “Peak of Mount Stupid” for No-Code Developers

In the Dunning-Kruger Effect, beginners often reach what’s called the "Peak of Mount Stupid"—a phase where confidence is high, but actual knowledge is still limited. For no-code developers, this peak occurs after they’ve created a few basic applications but have yet to encounter the more intricate challenges that come with real-world projects.

At this stage, many no-code programmers might believe they’ve mastered the platform. They might take on more complex projects without realizing the potential pitfalls ahead. This overconfidence can lead to errors, miscommunication with clients, and even stalled projects when they encounter problems they aren’t equipped to solve.

The "Valley of Despair" for No-Code Developers

Inevitably, the beginner no-code programmer will encounter challenges they aren’t prepared for, such as a complex client request or unforeseen technical roadblocks. This marks the entry into the "Valley of Despair," where the realization of how much they don’t know hits hard. It’s a humbling experience that often leads to frustration, self-doubt, and, for some, giving up entirely.

However, this valley is a necessary part of the learning process. It’s where true growth begins, as no-code programmers realize the depth and complexity of the field and start to seek more knowledge.

The "Slope of Enlightenment" for No-Code Developers

After weathering the Valley of Despair, the dedicated no-code programmer starts climbing what’s called the "Slope of Enlightenment." This is the phase where they begin to truly understand the nuances of no-code development, not just at a surface level but in a deeper, more strategic sense.

• Developing Real Expertise
  As programmers push through complex challenges, they start developing a more refined skill set. They begin to understand platform limitations, how to optimize workflows, and which plugins or APIs can save time and improve functionality. This stage is about building real competence, not just the illusion of mastery.

• Recognizing Patterns
  At this stage, no-code programmers start recognizing patterns in the problems they solve. They can anticipate potential issues and have a toolkit of solutions ready for common problems. This marks the transition from reactive problem-solving to proactive development.

• Confident but Not Complacent
  Confidence returns on the Slope of Enlightenment, but this time it’s rooted in real experience. The no-code developer has learned to balance confidence with humility, knowing there’s always more to learn but feeling equipped to take on most challenges.

The "Plateau of Sustainability" for No-Code Developers

Once no-code developers have honed their skills and built a solid foundation of experience, they reach the "Plateau of Sustainability." This stage represents the point at which they can consistently deliver high-quality projects, efficiently handle complex requirements, and troubleshoot effectively.

• Building Reliable Systems
  At the Plateau of Sustainability, no-code programmers are no longer struggling with the basics. They can now build robust, scalable systems that meet client needs. This stability allows them to take on more significant and more lucrative projects with confidence.

• Continual Improvement
  The Plateau of Sustainability isn’t about stagnation. Instead, it’s about continuous improvement. Developers on this plateau are constantly fine-tuning their processes, learning new tools, and finding ways to deliver better results faster. While they’ve achieved mastery of the no-code platform, they never stop learning.

• Mentorship and Community Engagement
  Developers at this stage often give back to the community. They become mentors, sharing their knowledge with beginners who are still navigating the early phases of the Dunning-Kruger Effect. This engagement not only helps others but also reinforces their understanding.

Overcoming the Dunning-Kruger Effect as a No-Code Programmer

To successfully navigate the stages of the Dunning-Kruger Effect, the Slope of Enlightenment, and the Plateau of Sustainability, no-code programmers should follow these strategies:

• Acknowledge What You Don’t Know
  Stay humble in the early stages of no-code development. Recognize that what feels easy at first is only the beginning, and there is always more to learn.

• Seek Mentorship and Feedback
  Surround yourself with experienced developers who can provide constructive feedback. This will help you identify your blind spots and accelerate your learning curve.

• Embrace Challenges and Failure
  Don’t shy away from difficult projects. Embrace the mistakes and frustrations that come with the Valley of Despair. They are stepping stones to greater understanding.

• Invest in Continuous Learning
  Mastery is not a final destination; it’s an ongoing process. Stay curious, take courses, and experiment with new no-code tools and techniques to keep growing.

• Contribute to the Community
  Once you reach the Plateau of Sustainability, consider becoming a mentor or contributor to the no-code community. Teaching others will reinforce your expertise.

Hope you will be more self-aware after reading this.

Help me!

If you enjoyed this post and found it helpful, Kindly consider supporting my work by buying me a coffee! Your support helps me create more valuable content and continue sharing useful resources. Thank you!

Skeleton loading is a placeholder component that mimics the structure of the application’s content while data is being loaded. Instead of showing a blank screen or a simple spinner, one can display a greyed-out or animated placeholder resembling the content that will soon appear. This gives the impression that something is happening in the background and makes the wait feel shorter.

Skeleton loading has become a popular UX feature across applications, helping to improve user experience by indicating that content is being loaded while minimizing frustration caused by blank screens.

Here is how you can create one in bubble.io:

Step 1: Decide the place for skeleton loading

Generally, don’t use skeleton loading for the whole page but identify the components that are taking time in loading the data. In most cases, it is a repeating group loading data on page load.

Step 2: Prepare the final output that will be seen after the data is loaded

Here in this example, this is how the final Repeating Group will look like with data!

Now let’s see this Repeating Group’s setup:

Once the output Repeating Group Setup with its component and its layout, it is time to go for the next step.

Step 3: Setup Skeleton Loading Repeating Group

Duplicate the output repeating group without its child groups and add the HTML element in place of Group main. Element tree will look like shown below:

Now this Duplicate Repeating Group’s data source will be arbitrary text split by(,), and the data type will be text. Here is what it will look like:

Now as per my output Repeating Group, I want to show one row only as a skeleton loading that is why I have used 4 times 1. If I wanted to show 2 rows, I would have used 1,1,1,1,1,1,1,1 as arbitrary text split by(,). This will vary as per your output repeating group setup.

Now, About the HTML element that we placed inside this skeleton Repeating Group or Duplicate Repeating Group. Here is the CSS I have used in my case:

Here is the CSS:

<div class="skeleton-item">
    <div class="skeleton-thumbnail"></div>
    <div class="skeleton-content">
        <div class="skeleton-throb"></div>
        <div class="skeleton-throb"></div>
    </div>
</div>

<style>
.skeleton-item {
    padding: 16px;
    border-radius: 8px;
    width: 100%;
    height: 100%;
    box-sizing: border-box; /* Ensure padding is included in the width/height calculation */
    position: absolute; /* Position relative to the container */
    top: 0;
    left: 0;
}

.skeleton-thumbnail {
    background-color: #000000;
    width: 100%;
    height: 60%; /* Allocate 60% of the skeleton-item's height */
    border-radius: 8px;
    margin-bottom: 8px;
}

.skeleton-content {
    display: flex;
    flex-direction: column;
    gap: 6px;
    height: 40%; /* Allocate the remaining 40% to the content */
}

.skeleton-throb {
    background-color: #15302d;
    height: 10px;
    width: 80%;
    border-radius: 4px;
    animation: throbbing 1.5s infinite ease-in-out;
}

@keyframes throbbing {
    0% {
        opacity: 1;
    }
    50% {
        opacity: 0.5;
    }
    100% {
        opacity: 1;
    }
}
</style>

Now you can customise this as per your understanding of HTML and CSS or you can use Chat GPT to modify this as per your repeating group or container.

Basically in my case, I have put placeholders for the image element and 2 text elements

Step 4: Hide & Show condition of output and skeleton loader Repeating Groups

• Both repeating groups should be ‘collapse when hidden’

• Duplicate/Skeleton loading repeating group will be visible on the page load

• Output Repeating Group will not be visible on the page load

• Duplicate/Skeleton loading repeating group will not be visible when the Output Repeating Group’s data is loaded

• Output Repeating Group will not be visible when it is loading the data and will be loaded only when its data count is more than 0

  

  And here is how it will look in the end

  

  Step 5: Best Practices to consider for using Skeleton loading

  • Minimal Overhead: Keep your skeleton design simple to ensure it doesn’t impact performance. Avoid too many elements or complex animations.

  • Mobile Optimization: Ensure the skeleton loading screen looks good on mobile devices by testing responsiveness.

  • Consistent User Feedback: Combine skeleton loading with other feedback mechanisms, such as progress bars or subtle loaders for better UX.

With a bit of creativity, you can take this feature to the next level, adding your animations and personal touches. Happy no-coding!

Help me!

If you enjoyed this post and found it helpful, Kindly consider supporting my work by buying me a coffee! Your support helps me create more valuable content and continue sharing useful resources. Thank you!

Step 1: Install this free plugin

• 🤌 Markdown Pro is a free plugin created by Rico and by doing so he has done a great service to the bubble community. Here is the plugin Link: https://bubble.io/plugin/%F0%9F%A4%8C-markdown-pro-1664737464989x536991279033614340

Step 2: Setup in Bubble Page to convert from Markdown text format

• 

  As you can see in the above image, there is an element called ‘🤌md-to-html’ that you will find on the design tab after installation of the plugin.

• Then set the element as shown below:

  

  Make sure you provide Open AI’s response in ‘md to convert’ input of element.

• Select a pre-defined style as shown in image below:

  

  Step 3: Setup in bubble page to show converted content

• Add an HTML Element on the page as a visual output of Open AI’s response where the User will see the output of their prompt.

  

  Here is how you set the output:

Now run this on your Page.
Here are the overall steps we followed to achieve this:

• Receive Open AI output

• Pass that output into markdown text to the HTML element

• show that HTML converted text into HTML output.

  Hope this will reduce your efforts!

Help me!

If you enjoyed this post and found it helpful, Kindly consider supporting my work by buying me a coffee! Your support helps me create more valuable content and continue sharing useful resources. Thank you!

OAuth 2 is a way for apps to get permission to access your information without needing your password. It uses tokens, which are like temporary keys, to give specific access to your data. Imagine a valet key for your car that only allows driving, not accessing the trunk. This keeps your main password safe and only grants limited access. It's widely used by services like Google, LinkedIn, Salesforce, Zoho, and Facebook to let other apps connect securely.

How to start? With basic setup

For this, let's take an example of Salesforce CRM. Why? because there is already too much content for Google and Facebook. lol :) and on a serious note, the Concept of OAuth 2 is the same for all.

Create an account on the Salesforce website, verify your email address, and fill in all basic information. Open Salesforce OAuth API Documentation in another tab.

Now Go to Settings -> Open Advance Setup -> Home -> APPs -> APP Manager -> New Connected APP

Then set up your new application like I have mentioned below:

Now Here is some concept clarification:

How does this OAuth 2 flow work?

• The bubble app will request an authorization code

• Salesforce will either accept or deny the request and redirect the user to redirect URI

• If Accepted, the redirect URI will have an authorization code as a query parameter

• Based on the authorization code, the bubble app will ask for a token exchange

• In exchange for the authorization code, the bubble app will receive an access token and a refresh token

• Based on the access token, the bubble app will ask for details authorized in the API Scope

• the access token will expire

• bubble app will ask for details next time and if the access token is expired, bubble app will use a refresh token to get a new access token and ask for details again via a new access token

Let's make ourselves familiar with the basic definitions of keywords we are going to use.

What is redirect URI?

In OAuth 2, a redirect URI (Uniform Resource Identifier) is the URL to which the authorization server sends the user back after they have granted or denied permission to the application. It acts as a callback URL where the authorization code or access token is sent. This URI must be pre-registered with the authorization server to ensure the response is sent to a trusted destination, enhancing security. It's like a return address on a letter, telling the server where to send the response. This address must be registered in advance to ensure it’s safe and trusted.

What is an authorization code?

An authorization code in OAuth 2 is a short-lived code that an app receives after a user grants permission. The app exchanges this code for an access token, which it uses to access the user's data. This process keeps the user's credentials secure because the app never sees the user's password directly.

What is an access token?

An access token in OAuth 2 is a security credential that allows an app to access a user's data from another service. After the user grants permission, the app receives this token and uses it to make authorized requests. It's temporary and limited to specific actions, ensuring secure and controlled access to the user's information. The app uses this key to do specific things, like read your emails or access your photos, without needing your password. It's temporary and only works for the actions you allow via scope.

What is a refresh token?

A refresh token in OAuth 2 is a special token that allows an app to obtain a new access token after the current one expires. This helps the app maintain access to the user's data without needing them to log in again. It's used to ensure continuous and secure access over a longer period.

What is the scope in OAuth 2?

In OAuth 2, a scope is a parameter that specifies the level of access the app is requesting from the user. It defines what actions the app can perform and what data it can access. For example, a scope might allow an app to read your emails but not send them. This helps users understand and control what permissions they are granting to the app.

What is client ID in OAuth 2?

In OAuth 2, a client ID is a unique identifier assigned to an app when it registers with an authorization server. It's used to identify the app requesting the OAuth flow. Think of it like a username for the app, which helps the authorization server know which app is requesting access to user data.

What is client secret in OAuth 2?

In OAuth 2, a client secret is a confidential key assigned to an app when it registers with an authorization server. It's used along with the client ID to authenticate the app and ensure that the request is coming from a trusted source. Think of it like a password for the app, helping to keep the communication secure.

You can find the client ID and secret in the manage connected app section of settings shown below

What does content type as application/x-www-form-urlencoded mean?

The content type application/x-www-form-urlencoded indicates that data sent in an HTTP request is encoded as key-value pairs, separated by & and with each key and value separated by =. This format is commonly used when submitting form data via HTTP POST requests. For example, name=John&age=30 is a typical representation of this content type.

How to Setup up OAuth API calls in Bubble APP?

Step 1: Request authorization code

Here is the API doc link for this.

In the bubble app, Create a button from which you need to initiate authorization and create the action 'Open an external website'. The destination will be similar to that shown in the image below

Now 'MyDomainName' is the same as your salesforce account subdomain which you can see in the URL when you open your your salesforce account.

When the user clicks on this button, the bubble app will redirect you to this URL and it will ask you to log into a Salesforce account then it will redirect to redirect URI you had set up and added in the button link.

This URL will have a query parameter named 'code'. For me, it was like this: https://unicotasky.bubbleapps.io/version-test/salesforce?code=aPrxI5eherH6PXZaIC0jwHd4esNOZqUHE_ub76CHD.JJj5W5iU54fhOCG87qYsSA3d8e65UtOA%3D%3D

Step 2: Request access token

Now we have to set up the request access token. Here is the Salesforce API Doc

The header will have the content type as application/x-www-form-urlencoded

Body parameters will have grant_type(static), code(dynamic), client_id (static), client_secret(static) and redirect_url(static).

In the Bubble API connector, it will look like this

Now put the code here and initialize the call, then save the response.

Make sure to convert the code as URL Parameter to text.

This means code=aPrxI5eherH6PXZaIC0jwHd4ehTG6AIWy5hT6F7Wa10T5A.btFkMQdrYdJ2j.pA714_oiXiw6g%3D%3D

is code=aPrxI5eherH6PXZaIC0jwHd4ehTG6AIWy5hT6F7Wa10T5A.btFkMQdrYdJ2j.pA714_oiXiw6g==

when you are using this in the body of an API call.

Successfully initialized call will look like this

Once initialized, Create a workflow on your redirect URL Page which you can execute either on 'Page load' or 'Do when condition is true'

Then I save the response to this action into the database in which I need access, token, refresh token, and expired by. Make sure to protect this data with privacy rules!

Step 3: Get Data before the access token expires

Here is the Salesforce API Doc reference.

Now Suppose you want to get data on accounts from the salesforce account of your user. You have an access token in DB that is not expired.

Here is the endpoint you need to use for this:

In Bubble, the API Setup will be like this:

and When successfully initialised call will look like this

Now I am creating a button which will only show If I have completed Step 2 successfully. As you can see, the data is empty, I haven't fetched it yet.

Now I am checking whether the token is expired or not.

When it is not expired, I will fetch the data from salesforce and show that in Repeating group.

Vola! Data from salesforce is visible now:

Step 4: Get Data after the access token expires

When you click the button and that time is greater than expire time, it means that access token is expired and we need new access token. So we will use refresh token to get it. Here is what the workflow will look like

This is how OAuth 2 works for all the platforms. There might be minor changes so always refer to API documentation to understand the nitty-gritty of their APIs.

Hope this will help you learn more about OAuth 2 and APIs in Bubble.

Help me!

If you enjoyed this post and found it helpful, Kindly consider supporting my work by buying me a coffee! Your support helps me create more valuable content and continue sharing useful resources. Thank you!

These API calls are not secure. Click here to find out how to secure them.