Reactive Programming: What & Why? — Part IV: The eCommerce Integration Case

The eCommerce Integration Case
Let’s take a moment to contextualize all of the topics we briefly touched upon in the previous sections.
Integrating with an external system is, in most cases, a careful act of balancing internal and external complexity.
This is because we want to keep our system as simple as possible for maintainability and performance reasons, while at the same time fulfill all the requirements for a successful integration, while avoid tightly coupling our system with the one we want to integrate with due to the fact that we want to be ready to adapt to changes (for example in their APIs) quickly without having to rewrite major parts of our own code.
On the first half side of the external complexity aspect (the eCommerce provider), all of this is further exacerbated by the fact that when it comes to the eCommerce space where money is involved and it’s important not to disrupt the user flow (e.g. the checkout flow, the shipping flow and so on), additional requirements need to be imposed, such as near real-time event dispatch (for a fast experience), data persistence and replay capabilities (we need to be able to reprocess something if we missed it for some reason) and tolerance for sudden spikes in traffic volume (like a Black Friday event) where we want to prevent a complete loss of service if we get overwhelmed by the external system, to name a few.
On the other half internal complexity side (our own customers that integrate through us to the eCommerce systems), the list of requirements does not get any shorter, because we interact with systems that are outside of our control and we need to be careful with them, for example by rate limiting our own output flow as not to overwhelm them, or being able to “pause” our own ongoing calls towards them for a while because they are unable to process what we are sending them but still be able to re-process this at a later date, just to make an example.
All of these additional requirements that we are considering end up adding other complexity to our own system that needs to be managed in the appropriate way to avoid creating unmaintainable system that we cannot operate and keep performant.
Ideally, we also want to insulate ourselves from the external system specific details as much as we can because we don’t want to mirror their own APIs, as that would make it very difficult for us to quickly adapt when things change and APIs get deprecated/removed.
Another point worth considering is the implicit complexity of integrating with different eCommerce systems that share some common parts that are similar enough that could be served by the same flow (think Authorization like OAuth 2) but not similar enough that a shared microservice would be useful.
To tackle all of this and many other requirements that we are not discussing in this first article, we decided that using the approach of Reactive Programming would be the right thing to do, after carefully evaluating its tradeoffs.
A quick look at these tradeoffs, in no particular order:
- Higher and steeper learning curve if one doesn’t have a background in Functional Programming already
- Lack of proper resources to learn how to treat a complex business logic and how to model it following the reactive methodology.
Luckily there is an increasing interest in the field and we are seeing more and more material on this side, but this was not the case just a couple of years ago. - A standardized way of defining a pipeline that we can leverage to implement a common series of operations on a given reactive collection, so that the similarities between the various flows for the eCommerce systems are encoded in the operations performed, but flexible enough that we can plug-in our own code for the steps where it makes sense to do so, e.g. to customize some result handling.
- A reusable approach of defining structures and series of operations that we can reuse in multiple places and even place into an internal library that reduces the amount of custom written code for shared tasks.
- An integrated approach to flow control/backpressure backed into the framework itself, which means that we don’t have to do it ourselves and we are, out of the box, able to leverage it and make our system more resilient with little to no effort.
- The possibility of testing each module in isolation by testing all the steps that are defined in the pipelines and verifying that they do what they promised.
We can easily do this because, ideally, each step is a specialized piece of code with just one responsibility and there is little to no coupling with other modules.
- Debugging experience is a bit different from the classical model because code is executed asynchronously now, but there are a lot of helpers from the framework itself that help, so the debugging experience ends up being more or less the same.
Conclusion
If you made it this far, thank you and congratulations!
Now that you know the basics of the topic, some tools of the trade and you have been introduced to some real-world examples, how do you really apply this knowledge in practice?
What are the next steps?
How do you properly design a reactive application?
Stay tuned for the second part of this article called: Reactive Programming – How and When where we’ll go in depth on how this fits all together, discussing how adopting the Reactive Programming approach might the right idea and when it might be best to do so, considering the existing design of a previous system and discussing the most common pitfalls that you are likely to encounter when adopting it.
<< Part III: Project Reactor >> Reactive Programming: How & When?
Request a Free Opportunity Assesment
RELATED CONTENT

Promote your SaaS to Prospective Customers via 20 Top SaaS App Marketplaces
SaaS App Marketplaces present huge opportunities as an acquisition channel. This is because your prospective customers are already using these established SaaS platforms making it easier to get found by your ideal customer. You can also tap into getting more business by association. Since some processes are built around certain products (eg. Shopify), certain businesses…

Nurturing and Building an Ecosystem around your Magento App Store Integration.
Introduction In today’s rapidly evolving eCommerce landscape, businesses are always looking for ways to differentiate themselves from the competition and deliver a superior customer experience. For many businesses, this means leveraging Magento, one of the leading eCommerce platforms on the market today. However, simply having a Magento App Store integration is not enough to ensure…

An App Store for Super Apps
The pandemic saw ten years of merchant technology adoption in three months. That has cooled a bit but there is really no going back. If you work in eCommerce, whether it be B2B or B2C, you know this statement is true. A key driver of BigCommerce’s scaling initiative is the “super app” trend, where payment…

An Integration Journey
After watching 100s of companies launch eCommerce Integrations and App, a pattern started to emerge. Most companies went through the same phases and many did the same mistakes or faced the same problems throughout their journey. Understand your Target Market Identify your target market and conduct market research to understand their needs and preferences. This…

The Ever-Growing Importance of eCommerce Connectivity
Expanding to multi-channel sales is critical in eCommerce. Selling across different platforms results in as much as 3X the engagement as selling on a single channel. Multi-channel sales rely on synchronized data so it requires each eCommerce platform to communicate with each other in as close to real time as possible. Check out this Anchor…

Essential B2B SaaS KPIs to Follow
I thought Id share this Popupsmart blog article on 3 essential B2B SaaS KPIs to follow. For most SaaS products and services, their most significant expense is the cost of acquiring a new customer. An excellent way to reduce this expense is by channeling resources and efforts into acquisition channels with the highest return. At…

5 Customer Acquisition Channels for B2B Apps
Check out this concise article on the Shoffi blog on five principal customer acquisition channels for B2B apps. As I mentioned on previous emails, the B2B SaaS market is getting more and more sophisticated and its not getting any easier out there. More and more apps are competing every day to attract the most traffic.…

Winning in the B2B SaaS Market
The B2B SaaS market is getting more sophisticated every day. A focus on intuitive, consistent and one-click experiences in UX design has substantially altered what users now expect from their software and has conditioned SaaS buyers in the enterprise to expect a slick, consumer-grade experience. Here is a short Forbes article that recently got my…

Hurricane Commerce, Enhances its Cross-Border Data Solutions with Itembase Connectivity
Hurricane’s Aura solution providing its landed cost engine, prohibited and restricted goods screening and denied parties screening and its Zephyr data enhancement tool are available to customers globally via the Itembase platform.

A Guide on Targeting B2B Customers
There are hundreds of eCommerce platforms out there and more are coming online every month. Supporting multiple platforms is a major challenge, even though each new integration provides new marketing channels that can be leveraged for increased awareness. Understanding the nature of each platform and how you can position yourself for maximum exposure is extremely…