Concerns, Pros & Cons

Concern #1: Visual Programming is not programming

I do realize that traditionally programmers (including myself) are against “visual” programming, as it has almost always been something targeting “less-knowledgable” people, and generally has always been a result of trading “fine-control” with “simplicity”, a trade-off that to put it mildly at least annoys any serious enough programmer.

However, that is not the case for CONNECT (or generally the graphic-based coding approach for async flows), as actually it offers more fine-control compared to callback arguments or async/await statements, and offers at least the same amount of control as Promise s do. In fact, if anything, sucn solutions enable us to do much more with the asynchronous flows that we develop. This is not giving away control, but rather simply dropping a constraint that is basically holding us back, although that constraint might be a property of any code that we’ve done for a long time and so we might be really used to it.

Concern #2: The application of such a tool would be limited

Well, since this approach does not remove control from developers and merely offers a more optimal representation, it is not just the case that stuff that you could build with such a tool (such as CONNECT) would be more limited, but actually you would become able to build much more complex async logics much easier.

To actually ensure that, we even built the Platform as a Service of CONNECT using CONNECT itself. Not only did it not impede us by any means, but we were able to accomplish it in a surprisingly fast time-span (4 days to a week, from the moment that we registered the domain and decided the names of various involved micro-services until it was ready to launch CONNECT instances for any registered user, put them to sleep after minutes of non-activity and wake them back up in response to requests).

Of course, it is notable that since this is an approach to asynchronous programming. There are other contexts of programming that will definitely not benefit from such an approach at all, just the same way that they would not benefit from Promise s or async/await statements.

Pro #1: Efficiency

Since this approach is designed on making the flow representation much more efficient and hurdle-free, it should naturally result in lower cognitive load on reading/writing the said representation, which would result in much faster development time (and hence much lower development costs). In other words, writing or reading this graph

would obviously be much easier and hence much less time consuming than this one:

Pro #2: Maintainability

This one is a natural result of the former. As it becomes much easier to read and follow the flow of the code, it also becomes much easier to debug it or make changes to it, which is one of the main hurdles of our current approaches to async programming.

In fact, the process becomes so seamless that we realized we could actually easily record the execution of graphs in CONNECT and replay them in real-time, not just helping greatly with testing and debugging, but also with performance inspection:

Pro #3: Performance

Since this approach to async programming actually enables much finer control over your asynchronous flow, it avails much better orchestration of tasks that can be accomplished in parallel to reduce response time. While you can do this with traditional approaches as well, since managing any non-trivial asynchronous flow would increase costs of development and maintainability, in many cases you would compromise some performance to keep those costs low. However, this graph-based approach you are enabled to delve into such optimizations without fear of increasing development/maintenance costs.

Con #1: Async Flows are inherently different

Since one of the first projects with CONNECT was a Platform as a Service, we quickly stumbled upon this one: now that async flows that we would usually do have became much easy to manage, we found ourselves quickly building much more complex flows and graphs (that we would have definitely avoided otherwise as their text-based representations would be too much to handle), which were accordingly challenging for us to understand and work with.

This also came up in pretty early user-feedbacks we collected: Most people are accustomed to thinking synchronously of their codes and services, and for a good reason: in a synchronous context, you can know for sure exactly which statement is being executed at each step, a control which you naturally loose by going the async route. And while these kinds of challenges are usually hidden behind the headache of callback hells, when we resolved those headaches, they surfaced and we quickly realized that generally you would need a different mental approach to your more complex async graphs than what you would to your sequential codes.

However, as per our admittedly pretty limited tests, it does not take so long for people to adopt the newly required cognitive approach, although there definitely is a learning curve involved here.

Con #2: Tooling

For CONNECT, we tried to re-use as much of the already available tools and technologies available to us and just add the graph-based representation that we intended. It is based on NodeJS, which means all NPM packages are available for it (which is one of the largest package repositories available out there). We even created a human-friendly JSON-based format for the logical graphs, so that you could easily version-control them (for example using git).

Despite all this, a pretty early on feedback we got from one of our pilot users was that he was asking for removal of some of the graph data so that he could read the git-diffs in an easier manner. In this case, although the human-friendly format helps a lot, still reading a graph from a JSON-file is just as efficient as forcing an asynchronous flow into a sequential format, it will inevitably be more challenging than usual. Although we are planning on adding a lot of git-focused nice features (including pretty diffs) for CONNECT flow graphs, it remains a fact that you would loose availability of development tools that have been for years developed assuming they are to aid with text-based codes, and some of them would need to be developed from the scratch for graph-based codes.