NoCodeSaaS - Building fast & maintainable apps - Issue #2

Ahoy there!

This week we’re talking about how to structure your app tp make it fast and easy to maintain.

I’m going to share some tips and tricks I use to make my app appear as fast as possible for users - most of them have no clue it’s built using no code!

When you’re starting to think of building your app on Bubble, there are a couple of really important decisions you have to make.

• How should I structure app - what pages do I need?

• How should I structure my database?

• What external services do I need to integrate with?

It’s worth taking some time to really think these things through - making the wrong choice can be a nightmare to unpick later and cost you a lot of time.

Let’s dive in on that first point - how to get your structure right.

UserLoop is a Single Page App - Which helps make it fast!

App Structure - Single Page or Multi Page?

Bubble can be pretty slow at loading new pages - even if you do tons of optimization - so if users need to move between pages in your app frequently it makes sense to build it as a single page app.

Building as a Single Page App was one of the first things I decided when building UserLoop.

This means all the customer interactions happen on one Bubble page, where new content is dynamically loaded depending on which menu item they click.

This might sound like a bit of an admin nightmare - but there are things you can do to organise things neatly and make it super easy to maintain.

Let’s start with the basics….

First of all you want to create a page where all the action is going to happen.

In my example this is called the ‘home’ page.

Everything the users do is going to happen on that page.

To make this possible we need to split that page up into sections…

Home Page Sections

The pink sections are fixed and are always visible.

The green section is dynamic - we only show content in there when the user selects a specific menu item.

Fixed Sections

For your fixed sections like the left navigation and headers, you can create a floating group which contains them all. This means they’ll always stick to the left side and you can make them appear / dissapear depending on the user’s screen size.

Dynamic Sections

This is where content is dynamically loaded in depending on which menu item the user clicks.

Here’s how this works…

1. When the user clicks on a navigation item from the left menu it adds a parameter to the current page url of ?tab=ratings or ?tab=account etc etc

2. The green section contains a stack of groups which by default are not shown on page load. They are set to only be visible when the blocks name matched the ?tab= value in the URL.

3. Each group contains a reusable element to keep everything easy to manage. I create a reusable element for each of the apps core functions like account, billing, settings etc.

Loading in each section dynamically without reloading the whole page makes things much quicker for the user.

Using Reusable Elements for each section makes managing all your various workflows and styles much easier.

Here's an example of all the Reusable Elements that power the main UserLoop UI

Backend Workflows

Once you’ve got a basic structure in place you can start thinking about workflows.

This is a huge topic in iteslf which we will cover in more depth in future… but as a general rule…

Use backend workflows wherever possible!

Using backend workflows means that workflows are sent to Bubble’s backend to be completed - and your user doesn’t need to sit watching a loading bar in their browser.

I use backend workflows to complete almost all user actions in my app. This helps make the front end fast and reduce the amount of times the user is waiting for things to load.

There is an excellent ebook by AmlieSolutions on this topic if you want to do a deep dive here… https://gumroad.com/l/the-ultimate-guide-to-bubble-performance

Database Toggles and Triggers

Another tactic I use in my app to keep things snappy is using database toggles & triggers.

Let’s use enabling / disabling email notifications as an example.

To do this, I create a database field called ‘ToggleEmailNotifications’ which can have a value of true or false.

In the front end, the user has a toggle which uses autobinding to determine whether the user has ‘ToggleEmailNotifications’ set to true or false.

I then use a backend workflow with a database trigger to listen for when the user makes a change to this setting, which then in turn can run the required workflow steps.

This workflow will run when a user turns on email notifications.

Combining reusuable groups, backend workflows and database triggers in this way can help you build very powerful features while still keeping your app’s front end snappy.

In next week’s issue we’re going to dive deeper into database structure, and how to set your app up for success by making the right decisions at the start of your build.

Thanks so much for reading, I’d really appreciate it if you would consider sharing this newsletter with your friends if you think they would find it useful.

I also love to hear your feedback so please feel free to drop me a line!