Starting BigCommerce Development: Thinking in SaaS

So you’ve decided to take the first steps toward learning how to “do BigCommerce development.” Maybe you’re looking for an eCommerce platform to build a custom storefront and have reason to think BigCommerce is the right fit. Maybe you’ve joined a BC-focused dev team and need to start learning the ropes. 

In any case, if you’re only vaguely familiar with the platform at this point and are ready to start reaching for the tutorials to “develop on BigCommerce,” you may need to start with a mindset shift. That’s particularly true if you’re coming from another eCommerce platform or a traditional monolith web framework.

The Open SaaS Platform

BigCommerce is, first and foremost, a SaaS (Software as a Service) platform. This means that the humming software engine at its core is locked behind the black box of a hosted service. As a developer, you have no way to “get at” the code that makes a SaaS product tick, and for developers with certain backgrounds, this is where our brains immediately grind to a screeching halt as we consider how to customize it.

My first introduction to BigCommerce in 2017 came after having been immersed in Magento for years. (Magento Enterprise became Adobe Commerce in 2018, and that’s still mainly where I’ve lived and breathed in the years since!) And Magento is as monolith a framework as they come. So at the prospect of building eCommerce sites on a SaaS platform, my first question was “How do I customize it if I can’t touch the code?”

BigCommerce bills itself as the Open SaaS platform, and for good reason. BC has virtually complete API coverage for all its operations, meaning that in almost all cases, anything BigCommerce can do, you can do too with a web services integration. And BigCommerce strives to make the product developer friendly. It has always been intended as an eCommerce platform that enables, rather than hinders, building beautiful custom shopping experiences. All while maintaining the stability and low cost of ownership that comes with SaaS.

But down to brass tacks. When you develop a BigCommerce store, you’re generally doing one of two things:

• Developing a custom theme using BC’s theme engine and coding language - a theme that then gets uploaded and applied to a store.
• Developing a separate web application that complements BC, providing its own custom functionality and usually interacting with BC’s various APIs.

So in a sense, there is no such thing as “developing on BigCommerce.” Rather, creating a custom BigCommerce store means stepping into a wider world - a world of simply developing web applications any way you want. Maybe that’s already the world you live in! And if so … this article is not for you. This is for the developer like me, familiar with a monolith like Magento or Salesforce, who can spend all day learning BigCommerce’s tooling and API protocols and still struggle with the question “Yeah … but what do I do with all that?” We’re going to envision a few scenarios illustrating what you do with all that, and in the process start the mindset shift that it takes to think in SaaS.

Scenario 1: The Simple Re-Theme

The simplest scenario is the BigCommerce store that just needs a face-lift. The built-in functionality is sufficient for your eCommerce needs, but you need to make the store your own with a custom presentation. 

Building a theme on BigCommerce’s default front-end is done with a custom toolset and runtime that allows you to view your emerging design in real time as you customize templates, layouts, CSS and JavaScript in the Stencil framework. Clone the default BC theme to get started, develop in a local environment hooked into your live store data, and end with a theme package that’s ready to upload and activate. In the end, customers are still interacting directly with the hosted SaaS product, but under the hood your custom theme code is building the presentation of the final webpages.

Scenario 2: Back-end Integration

In this scenario, with a custom theme now happily running on your store, you now need to work with BigCommerce data in some way, but independently of the BC web application that customers and admin users interact with. Let’s say, for example, that you need a custom ERP integration and must export orders periodically from BigCommerce to that ERP.

Your strategy here is to build a separate web application (we’ll use the ubiquitous term “middleware”) - with whatever tooling/framework makes sense for your needs, and hosted independently. This application can then communicate with BigCommerce’s web services for all its needs.

Scenario 3: Custom Front-end Functionality

Let’s get more complicated. You’ll commonly need custom functionality on your storefront that goes beyond what simple theme code can do. In this scenario, you need a full-fledged, customer-facing feature, complete with a unique UI and custom back-end data. How do you build that for your SaaS-driven eCommerce site?

The middleware app is still key here; all you need is a way to expose it in your BigCommerce storefront. Thanks to the theme framework’s support for custom page templates that can be applied selectively, any content page created in your store admin can serve as that entry point. Simply build a custom template with JS that performs the right form submissions or Ajax requests to your middleware, which likely also interacts with the BigCommerce API on the back-end. (BC also includes a robust Widgets API that allows for injecting snippets of content admin users can then drop in any area of a site.) Customers are still interacting only with the SaaS-delivered front-end, but a piece of that front-end is now interacting with your own app.

Scenario 4: Custom Admin Functionality

Now let’s say you require much the same sort of robust custom functionality, but for admin users of your store instead of customers.

This is where our “middleware” gets promoted to “BigCommerce App” (or single-click app). The concept of a separately hosted web application is still the goal here, but now we can add an OAuth layer that allows the application to be “installed” in BigCommerce via a built-in authentication workflow. The app then offers a window into its interface (whatever endpoint you choose to provide) that is embedded directly into the BigCommerce admin panel.

This is how commercial apps on the BigCommerce marketplace are architected, but you can easily build apps just like this that are private for your own store(s).

Scenario 5: Fully Headless

And now we come to the shining pinnacle of composable commerce: the fully headless integration. BigCommerce’s API-first approach makes it particularly well suited to a custom store front-end powered by the platform’s web services. In this scenario, we’ve flipped the previous pattern, with the customer interacting directly with your application, which talks with BigCommerce’s APIs to perform eCommerce functions (no doubt alongside integrations with other web services).

Conclusion

If the discussion of these web application scenarios has seemed like a no-brainer to you, I again congratulate you on an engineering background already suited for your BigCommerce journey! But for those developers like me who have built their web app careers in the world of the monolith, just being able to conceive of the workflows that make SaaS customization possible is half the battle of learning the platform. I hope I’ve helped you to visualize the possibilities, a foundation that’s at least as important as the ins and outs of BigCommerce itself!

Keep an eye out for more articles in this series, where we’ll get deeper into the areas of knowledge that will be important for your first steps “developing on BigCommerce!”