Blending code and nocode to scale your Bubble SaaS

Taking your Bubble app to the next level with custom coded components.

Welcome to this week’s NoCodeSaaS newsletter - the resource for anyone looking to build a successful SaaS business on Bubble.

This week’s issue is all about the rare occasions when you might want to take your Bubble app to the next level with some custom code. It includes a video overview of some of the custom code I’ve implemented in my app.

Sometimes on Twitter, it can feel like code and nocode are adversaries - with passionate people on each side trying to make their case that their approach is the best and the other is wrong.

I believe nocode and code technologies are highly complementary, and apps work best when there is a blend of both. Utilizing the strengths of each, applying them to specific use cases.

In a way, I don’t always think the phrase ‘nocode’ best describes what tools like Bubble do - they are a visual way to build software with a drag-and-drop interface and workflow-based logic.

In building my own app UserLoop (a customer feedback app for Shopify merchants) I have taken a pragmatic approach and mixed Bubble with many other technologies to build a product my customers are willing to pay money for.

I’ve worked for many years in traditional software development, and for about 5 years in Bubble now - and the benefits of choosing to build your app in nocode are clear.

In this issue, I’m going to look at the edge cases where introducing some custom code can help you take your Bubble app to the next level.

External Widgets

Depending on what your app does, you might want to let customers embed certain elements of it on their own websites. For apps like chatbots, feedback forms, surveys, social networks and many more - you often want to have parts of your application embeddable outside your main app.

This is a key part of my application. It lets Shopify store owners embed surveys within their checkout process.

There are 2 options of how you can achieve this with Bubble, and I have tried both so can share my experiences with both.

Using iFrames to Embed Bubble Pages in other apps

When I first launched my application this was the approach I took. Users could copy a custom iFrame embed code block and paste it onto their own website.

This had the benefit of being extremely fast to build. The embeddable widget was based on a page in Bubble, so it’s super quick to build and iterate.

This approach is great if you don’t need your iFramed content to interact much with the site it’s embedded in. If you do need to exchange data between the host page and the iFrame things can get a little tricky.

I needed to get things like the customer’s email address and order ID into my iFramed widget, so this required a tiny bit of custom JS to extract the data from the host page URL parameters and pass it to my iFrame.

I used this approach in my production app for about a year, but I had quite a bit of customer feedback that there a few issues with this approach.

• The iFrame could sometimes be slow to load. As it was a page from my main Bubble app, the load times could be a bit slower.

• With thousands of embedded pageviews this began to take a tole on my Bubble application capacity - capacity is used every time the widget was rendered on an external site.

• Every time I updated the Bubble app, anyone using the widget would be interrupted with the (highly annoying) Bubble ‘Please refresh this app’ notice.

Using a custom JS widget

I decided I needed to invest some time in making a native Javascript based widget which could handle showing the survey and collecting responses. This would solve all the issues above.

As you know - I’m not a programmer! So I decided to enlist some help from an amazing developer on Fiverr who helped me put the widget together.

However, before we started work on building the widget I needed to build an API in Bubble which would provide the data needed for the widget to render, and to accept responses back into Bubble.

The API would need two endpoints…

• GET. Provide the survey configuration info, questions, answer options and styling config

• POST. Accept customer responses in the Bubble backend.

This required building a custom JSON object in Bubble to return the custom object from the API.

I’ve put together a video overview to go along with this week’s newsletter to show you how it works.

The other crucial component is the javascript which powers the widget itself. This is fairly simple and hosted on an Amazon S3 bucket and cached via Cloudflare.

The javascript widget calls the above API endpoint when it loads to load the configuration, and then makes post requests every time a customer answers a question.

Here’s how it looks in the Shopify checkout..

You can try it yourself by making a free test order here.

Custom Plugins

Another area you can leverage custom code in Bubble is through custom-developed plugins.

Bubble Plugins are super powerful, and are able to leverage the huge library of node modules, meaning you can build super powerful server-side functions in code if you need to.

A good example of this in my application is a custom plugin I have built to handle some of the security + encryption when talking to the Shopify API.

My plugin is called Shopify HMAC Generator and utilizes the Crypto-JS library to the encryption and decryption my app needed to work.

It’s a good example that you can build almost anything in Bubble, even for complex use cases when you need to interact with external services.

I hope you found this issue helpful, and that it has helped inspire you to experiment with extending your Bubble application with some custom-coded components if it makes sense for your use case.

I’d love your feedback on the newsletter to help me with deciding what to cover in future issues.

If you haven’t already subscribed, check out the free No Code SaaS podcast where myself, Kieran (@nocodelife) and Glenn (@TheFlowAgency)

As always, you can reply to this email with any ideas or suggestions  Thanks for reading - and happy building!

James.