Component-based architecture in a nutshell

Here’s another slightly technical-focused story for you. This one is all about component-based architecture – what it is, how it works, and what’s so great about it. But perhaps it can also serve as inspiration for development leads and managers!

Dennis Keldermans and Dider Kerckhof from Apvine are here to discuss component-based architecture and the benefits it can offer both your development team and your customers.

What is 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, let’s define component-based architecture. In essence, it’s breaking development down into a set of functionalities that 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 – premade 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:

1. 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.
2. 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 much more agile software.
3. Independent lifecycles. As a result of the above point, each component can have its own lifecycle, updates, and so on without necessarily being tied to a larger project or product.
4. 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.
5. 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. In that case, 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!

About the authors

Dennis Keldermans and Dider Kerckhof are working for Apvine and have extensive technical knowledge of component-based architecture and its benefits to your development team and your customers.

About Apvine

Apvine automates business flows using low-code technology, building bridges not barriers. Low-code technology overcomes obstacles instead of creating them, connecting domain experts and developers with other members within your organization.