Frontend driven backend
From the moment I realized the Paradigm of software development has shifted, I became a firm believer in composable commerce. Then my next thought was that the frontend-developers are driving the technological changes. They’re using and mixing the backend and API more like utilities solving specific business needs while keeping a healthy buy vs. own balance.
Having it, all said - I think we’re witnesses of the next business revolution in which - the tech experiments, PoCs - but even production-ready apps can be explored and built by non-technical (or non-core technical) personas. That’s a profound change - when the marketing department can deploy their event application, experiment with customer segmentation, etc. No queues to the IT department, deployment cycles, maintenance costs.
When you look at the recent YC combinator batches with newcomers like WeWeb, UiFlow, and B-round, well-established companies like Retool, it becomes clear that Low-Code and No-Code tools are super hot. They’re also here to stay.
On the other hand - from when we had the first talks with the Vue Storefront potential users, it was three years ago and around VSF 0.4 version - the same question was and still is asked. How can I test XYZ without the full-re-platforming? Headless is excellent, but usually, you need to replace a legacy platform with improved architecture with another one. Migration to the MACH compliant stack can be the last complete migration you have.
But if there could be another way - implementing just some new features while operating the core platform as it is? If we can get this idea further - maybe there’s a way for any eCommerce (legacy or not) to test new products without the actual integration work.
Maybe we could have a standard like Google Tag Manager was for the snippets management - but the headless-tools orchestration and integration?
Is Composable Commerce a perfect architecture for the frontend-driven backends?
eCommerce with no backend
Two weeks ago, recording an interview to the CTO-CTO podcast, I got a chance to have a deep talk with the CEO of Snipcart. Not getting too deeply into the whole story (wait for the episode!) - one of the coolest features Snipcart has is that you can add it to your WordPress, HTML page, Webflow, PIM, JAMStack page, whatever website engine you have - just by an HTML snippet.
Its’ something like this:
You don’t even have to have a suitable products database - because anything needed to sell the product can be passed over the HTML attributes. Of course, there's a whole security stack on top of this simple mechanism - to validate if a user doesn’t manipulate the HTML tags over dev-tools, etc. (can be quickly done by anti-csrf tokens or background page scrapping + comparison.
You can build an eCommerce platform with no backend (actually, Snipcart provides you with the part of the UI - cart + checkout + the API and webhooks you can use to finalize the order).
Having this way of integration but for commercetools - could be super interesting. Snipcart did it for ease of use. Enterprise needs it for the relief of migration. I mean - the current CMS solution you have, the same PIM you have, switching just the checkout. Wow, this could be something. If you think niches - it could be rental, booking, subscription addon. Adding, not replacing just got away easier.
Frontend driven data bus
Then, I thought a little bit longer about the beauty of Snipicart’s integration. A crazy idea struck me. Wow! If we could potentially have all the customer’s related data integrated the way GTM (Google Tag Manager) and GA do - it could be a game-changer.
GTM data layers are a super easy tool for aggregating the customer’s session-related info and the visit.
If we can go a step further - adding client’s addresses, data, cart information - we can have unified data-bus processing the structured eCommerce data.
OK. And why is it so cool?
Integration marketplace
I can imagine a marketplace with the best-of-breed eCommerce tools: search engines, reco-engines, payment methods - integrated with just one click. If they could be “ported” to the Data Bus mentioned before - once the dataBus scripts are incorporated, adding new eCommerce integration could be just one click. No engineers engaged.
Micro frontends are absolutely a way to build these marketplace apps - having the component wrappers to Algolia, Constructor.io, Nosto, etc.
Micro frontends are great because they isolate the CMS/legacy pages from the new features/frameworks etc.
Strangler Fig pattern the other way
The frontend-integration-only pattern can lead us to even more exciting use cases. Imagine you’ve got the list of products rendered from your eCommerce platform (or PIM).
Something like:
Think of the example of GTM above. If you add a single line of JavaScript like
<script>dataLayer.push({ event: ‘product’, sku: ‘wj12-black’, name: ‘Olivia ¼ Zip …’ }) </script>
You can easily aggregate your product data and send it once per page to a middleware. Why do so? To not engage the backend developers in the data integration process. Having the marketplace idea in mind - this middleware can update and distribute the products or any other data from the legacy platform to new systems without the dedicated XML/SQL/RPC feeds.
Wrap up
OK, nice, but why is it so unique that you spent the whole blog post on this silly idea?
I’m not sure if it is the right idea for a completely new product. Say: Frontend Driven eCommerce Data Bus © ;-). It is probably too general, and it’s easier for new products to operate in narrow niches.
However, the integration barriers are the worst thing that enterprise software needs to overcome. The backend developers are in scarcity. I’d be super excited to see the next enterprise SaaS product integrated the easy way: low-code or no-code.
