Are Developers Right to Distrust Low-Code Solutions? Part 2—Architectures

Part 1 of this series explored how the answer to increased developer productivity shouldn’t be the extreme of black boxes, but a low-code solution that’s an “open box”—based on open standards and with a full view of the source. In Part 2, we’ll examine the development architecture in the context of low-code solutions.

Low-code solutions not only suffer from the “black box” perception of difficult or impossible customization, developers also cast a jaundiced eye on their architectures—antiquated, monolithic, and unfriendly to application deployment.

Monoliths—the Good and Mostly Bad

From a development standpoint, the advantages of monolithic architectures, where all the application logic and code reside in large and interdependent components, include being simple to develop and to deploy—at least initially. However, in the long run these advantages are outweighed by the disadvantages. Monolithic app services tend to be “tightly coupled,” making it difficult to isolate services for purposes such as independent scaling or code maintenance. If any program component needs to be updated, this often requires large portions of the application to be rewritten.

That, in turn, raises the specter of refactoring to improve performance, readability, portability or code adherence. A monolithic approach immediately puts you on a refactor course or dealing with bolt-on alternatives often provided by the software developer that try to add modern functionality to a dated architecture—but end up creating a second tier of apps.

Monoliths + Low-Code Solutions = Extra Work

Monolithic architectures common to many low-code solutions are much more difficult to understand, because there can be dependencies that aren’t apparent when looking at an individual service or controller since they’re baked into the solution. With many low-code solutions, you’re saddled with trying to manage the development, testing and production work for a monolith, minus the ability to develop, test, deploy and scale components individually. Scaling is challenging because you can’t identify and break out specific poor performing pieces to optimize them, and maintenance is a chore because while a monolith has fewer “moving pieces,” they’re hard to maintain because those pieces are all tightly coupled.

Developers are aware of these limitations and try to avoid them.

So, What’s the Answer?

The ideal would be to have the cloud capabilities provided by the likes of AWS or Azure at your disposal, combined with the ease of low-code deployment.

Developing on a serverless cloud-based platform allows the platform to manage and auto-scale the microservices and functions. If you combine this with a Node.js backend and a JavaScript-based frontend for web and mobile, you have a full-stack option. The benefits are manifold:

• Combining a serverless and low-code platform built on JavaScript allows organizations to meet demand for consumer-grade multichannel experiences using existing developer skills
• Different developers or even different teams can work on their portion of the application independently without conflicting with changes made by other teams
• Updates can be made without rewriting or redeploying the app code
• Code is reusable across apps and easier to maintain as functionality is isolated

The result is developers are freed to focus on app capabilities and user experience, while the platform manages the rest.

Disruptive Platforms Have Arrived, and That’s Good for Development

Traditional low-code vendors offering monolithic platforms are being disrupted by high productivity platforms designed to be cloud-native and standards-based with support for a serverless backend and microservices.

One of those disruptive high-productivity platforms is Progress Kinvey.

Kinvey and NativeScript let developers use JavaScript, TypeScript, Angular or Vue.js to write once for native apps across multiple platforms, plus have a rich collection of UI components at their disposal. Meanwhile, the Kinvey serverless backend auto-scales to the highest levels, has the flexibility to support frequent changes, and integrates easily into systems of record and authentication using a configuration-based, low-code approach. The modular architecture of a Kinvey application still requires that application updates be regression tested to ensure that the changes don’t break any dependent code. However, unlike a monolith, this doesn’t necessitate substantive rewrites to the application code or redeploying the entire application.

A modern serverless architecture married to the highest levels of developer control—that’s the answer to meeting the never-ending demand for consumer-grade multichannel applications.