What do you imagine when someone says Hub? 

It's a center or place to hold a collection of things or several kinds of things. And an Entando Hub is a repository (local, remote, public, or private), that contains components. To be more specific, the App Builder, the UI of the Entando Platform, can connect to one or more Entando Hub.

In my recent blog on Entando 7.0 release, I wrote a bit about the Entando Hub. You can check that out here. But, in this blog, I’ll give a technical overview of the Hub.

Before I start, let’s find out why we needed a Hub. 

In the previous blogs, we learned about the 4Cs. If you don’t know about that,  you can take a look at this blog. from the 4 essential roles of application composition, one thing is clear: the set of components built by creators are reusable and absolutely flexible. But, to make them easy to reuse, there was a need to create a Hub, where they could reside and be available to a larger audience. 

Now, the question is, what are some of the capabilities of the Hub?

The Hub lets you share Single Components, Component Collections, Solution Templates,  Packaged Business Capabilities (PBCs) that creators build.

Single components are a building block for apps. It  can be a page template, content template, micro frontend, microservice, UX Fragment,content type…

Component collections are a packaged set of single components. They are assembled components that are in some way functionally unrelated but useful to a Composer.  (e.g. a set of Page Templates, a set of content templates or content types + widgets + MFE or a mix of them)

Solution templates are a pre-packaged set of PBCs, component collections, and single components providing full-featured, domain-specific solutions. (eg: Task Tracker, Supplier Portal, Customer Portal, Partner Portal, E-commerce, …)

And PBCs are encapsulated software components that represent a well-defined business capability, recognizable as such by a business user, and packaged for programmatic access. 

Any and all of these can be assembled in the Hub, where new items and new versions are continuously made available. But to avoid errors or issues, we should follow some best practices.

• The PBCs and/or components we build as a creator must be well sized. It shouldn’t either be too small or too big. It should be business-driven with a definite business value. There are several scenarios in this case. For example, a PBC can have many components which can make it large, or it can have fewer components, making the size smaller. But in this case, a Composer may need to install several items to get what they need. It is a tradeoff between functionality and ease of use. Hence, we must judge wisely, making sure the component isn’t too large or too small. 
   
• Our Components and PBCs should be easily configurable. By this I mean, we must avoid hard-coded stuff. It is preferable to use separate configuration files or database tables to  store any value that’s needed in your component.
   
• It is best to use a package manager as it can help us with the right dependency versioning strategy. A package manager helps us by updating all the packages and/or software frequently. These packages run tests to check security and other things. It also saves us a lot of time.
   
• While we discuss these best practices, we must know that the Curator oversees the Hub, managing the components available there for the organization. Hence, the Curator should do a Security Analysis. They should perform a thorough analysis of the dependencies, security alert or code vulnerabilities.
   
• Use code quality metrics to measure and determine if the code we have written for the PBC is of high quality. Certain variables are checked under this quality analysis, like code complexity, portability, reusability, etc. 
   
• And finally, we should add proper documentation for our PBC. It’s the first thing that provides clarity about our PBC. This documentation should be made in such a manner that it is well understood by both business and technical people. Also, it is a good coding practice!

Now, it’s time we take a look at the Hub.

As you see here, there are many PBCs, Component Collections, Solution Templates, and Single Components under “Catalog”. After the Curator performs the validation checks, these building blocks made by Creators are published in the Hub.

How can we use the Hub?

This Hub can be used with Entando 7.0. This documentation can help us get started after installing the Hub on Entando 7.0. But in the upcoming blogs, I’ll definitely share how it can be installed in our App Builder. 

Is the Hub open source?

The Entando Hub is under the ​​LGPL-3.0 license and is open source. We can easily contribute to it by referring to this repository.

Lastly, before we wrap up, I’d like to explain the Entando Cloud Hub.

The Entando Cloud Hub is a SaaS instance of an Entando Hub that contains a public and private collection of components. 

Well, that’s all about the Hub for now. We are in the process of creating more tutorials around the Hub and those will be released over the next few weeks. 

But, for now, I would love to see you all try out the Hub for yourselves and send in your feedback to the comment section below!

Lastly, we at Entando are building an exciting community that spreads awareness of composability and modular applications. We call it the Modular Squad, and we’d love to invite you to join us and be part of this journey!

Thank you!