cool, but why?

I see two main reasons that make development of API micro-services more complicated than what they should be. First one is, that web-service logic is essentially asynchronous, which results in non-linear execution flows, while we are representing such flows in an extremely linear fashion, that is, a sequence of characters.

So, we do this:


doA().then(function(outA) {
  doB(outA).then(function(outB) {
    doC(outB);
  });
});

instead of this:

which specifically gets worse when the logical flow really gets non-linear:


doA().then(function(outA) {
  Promise.all([
    new Promise(function(resolve) {
      doB(outA).then(function(outB) {
        doD(outB).then(function(outD) {
          resolve(outD);
        });
      });
    }),
    new Promise(function(resolve) {
      doC(outA).then(function(outC) {
        doE(outC).then(function(outE) {
          resolve(outE);
        });
      });
    })
  ]).then(function(values) {
    doF(values[0], values[1]);
  });
});

compared to this:

pretty obvious what we are doing wrong, right?

i guess so ...

so whats the other reason?

for elaborating on the second reason, you should first get familiar with two different kind of logic used for describing products (in terms of programming them mainly):

micrologic

which is the kind of logic programmers understand and love. this is low-scope logic, probably not specific to the application domain of the product. imagine a code that sends an email, does a query in database, and greatly differs from

macrologic

which is the larger-scope logic of the product. think user journey, process analysis, or however context a product designer/manager/owner/whatever might like to describe the product. this goes far less into details, as this cares not for example on how an email is sent, but that it does get sent after some specific thing happens.

based on my experience, mixing these two is the other key reason that developing backend logic (which is most of the time the main product logic), or product logic in a more general sense, is an expensive and time-consuming task. programmers are comfortable doing micrologic, but when it comes to macrologic, it falls upon product managers/designers or people responsible for that kind of thing in team. they need to come up with a description that they cannot test since they cannot implement actually, then they need to communicate that description to developers, subsequently developers need to again describe their understanding of that description to machine language (whatever programming language they are using). it is just then that the whole thing can be tested and iterated upon. miscommunications easily make up for a lot of effort that goes in to this process, and generally it is rather obvious why this is a lazy and time-consuming process.

so the idea here is to avert that. the CONNECT platform is not there to replace traditional programming 100%. it is a tool for describing and easily testing macrologic, so it naturally requires far less technical knowledge than traditional programming and can be operated by people with little to no prior technical knowledge. it also heavily relies on extensibility of native codes, as that is how the micrologic gets injected and added to the logic.

interesting ...

interested?

this is a really early stage project. I have not tested this in production environment and the platform is currently really feature-empty. of-course, if you still want to give it a test run and/or maybe even contribute, simply do the following:


# clone from git
git clone https://github.com/loreanvictor/connect-platform.git

# go to the directory
cd connect
cd platform

# install dependencies
npm install

# go to panel directory and install its dependencies
cd panel
npm install

# build the panel
npm run angular-build

# go back and start the project
cd ..
npm start

what is the idea?

cool, but why?

so whats the other reason?

micrologic

macrologic

interested?