@bashir the decision not to use Sync 2.0 was based on a number of early findings that made it a deal breaker for the stakeholder at the time of the assessment (April 2019).
A couple of people who have looked into it might chime in (@wyclif, @willa, …) . One of the major issues found with Sync 2.0 back then is that it did not cater properly for disorder. It was, apparently, possible to quickly bump into issues such as “I can’t load that obs because it refers to an encounter that I don’t know (yet) about.” This very kind of issue was of high concern and led to redesigning a tool that would fully support this from the outset, enforcing so-called “eventual consistency” at the receiving end of the data, whatever the route in between (such as remote ActiveMQ nodes for instance).
Another point that was raised by @raff at the time was that it was probably a good idea to work at the database level 1) performance wise and 2) because the DB schema in OpenMRS was actually quite stable. One of the advantages of APIs is that they hedge against DB schema changes, and in the end this was not such a good argument when looking at OpenMRS’ history. Performance however was rather the key factor. Early in the days of DbSync we could show that the large test dataset could be synced entirely in less than four hours with end-to-end encryption turned on.
For EIP purposes there was indeed a strong push for Camel, which still makes sense. Keep in mind as well that the solution needed to cover both 1) sync and 2) integration needs. It is intended to be used to sync patient files “from field to HQ” as well as to integrate OpenMRS with other systems locally (such as an ERP.)
I realise that it is a pity that the assessment wasn’t made more public a year ago. I’m trying to recollect the info for you here above. However even in apha/beta stages, DbSync has started to show promising results quite fast, which has reinforced our take that this was probably an acceptable approach and appropriate tech stack, even though we do revisit some assumptions still as of now (cfr the other thread).
Happy to speak about it any time.