Challenging implementations: how did you resolve them?

In the perfect world, in which I wake up to sun beams on my face and a coffee magically appearing on my night stand, commerce tools is the center, sole core of my eCommerce solution. I can use all features as intended and to their full extend.

TLDR;

There was no coffee on my night stand. Kafka and commercetools works great for publishing, but is kind of difficult for receiving messages.

Full story:

In my past experience, there was no coffee when I woke up and also eCommerce was intended to be the center, sole core, but of course other systems within a large cooperation don’t want to just throw in the towel. 
In the past, we therefore had to incorporate a system that was fully committed to event driven architecture. They wanted to be notified of every change that happened to write it in their database. And they wanted to notify us of every change.

This was obviously in total contrast to our approaches. However, one part was easy - notifying them of every change: Commercetools makes this an easy-to-solve problem with the subscriptions. Every cart update would trigger a microservice that would simply push the cart into a kafka topic. Done.

The getting notified part was a little more difficult. We can’t just take an incoming event and translate it to a cart.
After mapping the incoming data to a format we could use, we need to figure out what changed in order to update. And while mapping, we noticed that we are not even interested in a lot of updates. To keep it short: We built a configurable filter to find out which events we need to look at, and which we can ignore. 

Then we mapped the data to a cart like object and started comparing it to the existing cart. We thought about using the sync lib from commercetools (not the project sync, a - i think now - deprecated lib for figuring out updateActions between two objects), however we’ve made bad experiences with that and it is also not suitable for carts. Therefore, we started to write our own logic that would extract all the relevant changes and build updateActions, which were then sent to commercetools.

So far so good. But as there is still no coffee on my night stand in the morning, this wasn’t the end of it. 

After deploying, the other system started to spam us with updates every time we ourself sent them an update. They were “unable to fix that on their end”. There are multiple ways of solving that, we ended up using an identifier that marked an object on their end to have been edited by us. Then we could add that to the filter and ignore the looping event. 

Bottom line (literally): Interesting challenge to write that abstraction layer and implement the switch between these completely different approaches. 

@Patrick Burkart  thanks for your response and great feedback. I’ll make sure to pass it on! 

And for what it’s worth, if we ever meet in the real world (hackathon, community meetup), coffee is on me. ☕😊