The Components That Make Up An Entando Application - Frontend and Backend Components
Tags: components, entando, microservices, microfrontends
Published: 2021-08-12 09:24:08

Hey my fellow developers,

In the [previous blog post](https://dev.to/avdev4j/sharing-components-in-a-marketplace-for-developers-with-entando-bundles-20n2) of this bundle series, we learned what bundles are, how they are used and what goes inside them. We also learned that bundles are used to package components (or updates) to an Entando application.

This blog post is the first in a series that dives into the details about components including how they are defined, how they are deployed to an Entando Application, how they can be configured, and how they are rendered in your application.

We’ll cover frontend and backend components first, followed by CMS components, and finally page components, user management and internationalization.

## What is an Entando component?

According to the official documentation:

> An Entando component - simply referred to as component - is a piece of reusable code that can be used in an Entando widget, page or application. Examples of components are widgets, micro frontends, content-types, labels, plugins (microservices), and static resources

Entando bundles are made up of one or more components. We will cover all of the different types of components and how to define them in your bundle in the next sections.

All of the code and examples in this article are taken from the [Standard Demo Bundle](https://github.com/entando-samples/standard-demo-bundle). If you want to install it, you can follow [this tutorial](https://dev.entando.org/v6.3.2/tutorials/samples/install-standard-demo.html#introduction).

## Microservices
### Plugin

The plugin component is used to deploy microservices. Each plugin is deployed onto Kubernetes and runs as a pod.


``` yaml
name: standard-demo-banking
image: 'docker.io/entandodemo/banking:0.0.18'
dbms: none
healthCheckPath: /management/health
ingressPath: /banking
roles:
 - task-list
permissions: []
```


* **image** The docker image used to create the plugin.
* **dbms** The database management system the plugin will use (e.g. mysql, postgresql, none…).
* **healthCheckPath** The health check path that kubernetes will use to check the status of the plugin deployment.
* **ingressPath** the ingress path to assign to the plugin deployment
* **roles** contains a list of roles the plugin will expose to Keycloak and use in the backend code to add security logic.
* **permissions** is a list of Keycloak clientIds / roles to bind to each other to allow the microservice Keycloak service account to reach other services.

The plugin is deployed as a custom resource into Kubernetes. This means you can check them with the following command with ENT cli or directly with kubectl.


``` bash
ent kubectl get EntandoPlugin
```

![Screenshot_20210602_at_15.35.21_d0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ku3bkc3z0gn5qzfqii8a.png)

## Frontend components
### Widget

The widget is a self-contained piece of frontend logic (html, javascript, micro frontend, etc.) that can be added to a page.


``` html
code: credit_card_user_apply_form
titles:
 en: Credit card user apply form
 it: Form di applicazione carta di credito
group: free
customUi: '<#assign wp=JspTaglibs[ "/aps-core"]><link rel="stylesheet" type="text/css" href="<@wp.resourceURL />standard-demo/widgets/creditCardApplyForm/css/main.css"><script nonce="<@wp.cspNonce />" async src="<@wp.resourceURL />standard-demo/widgets/creditCardApplyForm/js/runtime.js" ></script><script nonce="<@wp.cspNonce />" async src="<@wp.resourceURL />standard-demo/widgets/creditCardApplyForm/js/vendor.js" ></script><script nonce="<@wp.cspNonce />" async src="<@wp.resourceURL />standard-demo/widgets/creditCardApplyForm/js/main.js" ></script><credit-card-user-form />'
```




* **code** is the unique identifier for the widget.
* **titles** defines the localized titles for the widget.
* **group** defines the owner group of the widget.
* **customUi** contains the freemarker code to render your widget. Note that it’s also possible to use the **customUiPath** instead, if you want to use a dedicated freemarker file.
* **configUi** is an optional field to add a configuration UI for the widget. You can add a configuration UI using the component descriptor:

``` html
configUi:
  customElement: my-widget-config
  resources:
    - <bundleid>/static/js/main.js # The resources necessary to the custom element to render the configUI, like the code
```


* **customElement** The name of the custom-element used to render the configUi
* **resources** an array of static files to render the configUi.

![unnamed_1_d0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zyqpz3hj6ok9wy34a8uf.png) 


_Widgets are available under the menu: Components > Micro Frontends & Widgets_

![Screenshot_20210531_at_19.15.18_d0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c7y0njq3uc67es9m94cy.png) 

_Example: This widget renders a form on the page._


### Fragment

A fragment is a piece of reusable code you can insert into your pages and widgets through a freemarker directive (e.g. a script import).


``` html
code: insurance_inclusions_footer
guiCode: '
<#assign wp=JspTaglibs["/aps-core"]>
<script type="text/javascript"  src="<@wp.resourceURL />static/js/bootstrap.min.js"></script>
<script type="text/javascript" src="<@wp.resourceURL />static/js/mdb.min.js"></script>'
```

* **code** is the unique identifier for a fragment. It’s used to reference the fragment from a widget or a page.
* **guiCode** is the fragment code that will be included in the DOM.
* **customUiPath** can be used instead of **guiCode** if you want to use an external freemarker file.

It can be used like this in a page or widget:


``` html
<@wp.fragment code="insurance_inclusions_footer" escapeXml=false />
```

![Screenshot_20210618_at_12.15.27_d0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1gywejviuzvu7smigkmo.png) 


_The widget is available under the menu Components > UX Fragments_


### Static resources

A static resource is an Entando component that allows developers to include static files in a bundle. It could be Javascript files (e.g., to import a library), images, documents, and CSS files.

You need to create a folder called “resources” and all the files inside this folder will be made available as static resources to your Entando application. This means you don’t need to explicitly declare each resource in the main bundle descriptor. In Entando App Builder, the “resources” folder is renamed to match your bundle id, you can access it in the _Administration > File browser _menu.

Static resources can be used like this in freemarker templates:


``` html
<link rel="stylesheet" href="<@wp.resourceURL />static/css/all.css">
```

![Screenshot_20210531_at_19.38.33_d0](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l1gtv1bilhgw6feaka29.png)
 

_The files can be browsed in the menu Administration > File browser_


## What’s next

Now that we’ve covered the Entando components to deploy and install backend services and micro frontends to an Entando application, the next blog post will cover how to deploy and install CMS components to your application using a bundle.