Component-based architecture in a nutshell

Introducing component-based architecture

Of course, Mendix low-code allows you to use a component-based architecture, which is part of what makes it such an agile and flexible tool. But more about that later. First, what is component-based architecture? In essence, it’s breaking development down into a set of functionalities you group together (into ‘components’) often with the intent to reuse as and when you need. A component could be a UI element, logic, data, or many other parts that make up software development.

What does that really mean? An easy way to think about it is lego. Whatever you’re building (in the lego-verse), it’s mostly just a matter of finding the right building blocks - pre-made components - that can be reused and slotted in wherever needed without requiring a huge redesign or modifications to the whole. Each block is a stand-alone piece, a self-contained module that serves a specific function (of course, several blocks stuck together can then also become a component, albeit a slightly more advanced one). That’s component-based architecture.

The traditional alternative to this is a scenario where every function and module is interconnected to the whole - everything built in one big stack as one complete application. By the way, micro-service architecture is not the opposite of component-based architecture. It is sometimes an example of component-based architecture, but not always.

Why we’re fans

As for the benefits of a component-based architecture, there are many depending on the specific use-case, but here are some of the highlights:

• Efficient workflow. Since components are stand alone structures, they can be made in parallel timing with other parts of any given development track. A project can be broken down into defined components at the outset and multiple teams can work on separate components simultaneously.

• Agility. Again, since components are stand alone structures, you can edit or upgrade any particular component you wish without it having a negative impact on the app or website as a whole. This makes for a much more agile software.

• Independent life-cycles. As a result of the above point, each component can have its own life-cycle, updates, and so on without being necessarily tied to a larger project or product.

• Global run-time. With component-based architecture, there’s one run-time for everything. This means there’s no need to fine-tune the intercommunication between components! Also, (for better or worse) either everything works or nothing does.
  Note: the opposite is true of micro services, in which every service has its own runtime and context.

• Mendix Marketplace. Component-based architecture means you’re constantly creating valuable, reusable components, which you can (if you wish) sell or share on the Mendix marketplace. Similarly, you can find components from other developers there. All in all, this means a greater variety of tools and possibilities. But it’s not always the best way to go. Particularly when it comes to smaller and less complex projects, planning out your component-based architecture approach may be more work than it’s worth.

Component-based architecture in action

To wrap things up, here are two examples of how we’ve benefited from component-based architecture in past projects at Apvine:

First, how it has created value for us internally. Once upon a time, while building an app for one of our lovely clients, we had a technical obstacle to overcome - accepting web socket communication (pushing data from the backend to the front end). We decided to create a specific component to do just that, and since then we’ve reused the little module countless times on various projects with various customers.

Secondly, how component-based architecture creates value for our manufacturing customers! While working on an Overall Equipment Effectiveness (OEE) application, we saw an opportunity to streamline the app for the client’s benefit. By splitting up the OEE module into components for availability, scrap, performance and quality, they (and other companies too) were able to reuse them throughout multiple projects, streamlining development time and flow in the process.

And that’s component-based architecture in a nutshell. Questions? Comments? Let us know!