diff --git a/vuepress/docs/next/docs/create/component-gen-tech.md b/vuepress/docs/next/docs/create/component-gen-tech.md index 478fd94d07..f8959abef1 100644 --- a/vuepress/docs/next/docs/create/component-gen-tech.md +++ b/vuepress/docs/next/docs/create/component-gen-tech.md @@ -1,25 +1,25 @@ # Component Generation Technologies -When generating a microservice using the Entando Component Generator there are a number of technical choices that need to be made +When generating a microservice or micro frontend using the Entando Component Generator, there are a number of technical choices that need to be made: * Microservice code - * If you're interested in using Quarkus in your Entando app, contact us on the [Forum](https://forum.entando.org/) or [Community Slack](https://join.slack.com/t/entandocommunity/shared_invite/zt-g609owdv-2K~YRh8zrI6lqlWo4aFWUw) and we'll help you get started. - * If you're considering non-Java based microservices, [here is a definition of an Entando plugin](../curate/bundle-details.md#microservices-specifications), including information on the runtime contract required to use them. + * If you're considering microservices that are not based on Java, here are the [specifications of an Entando microservice](../curate/bundle-details.md#microservices-specifications), including information on the runtime contract required to use them. + * For a JavaScript example, see the Node.js microservice in the [API claim tutorial](../../tutorials/create/ms/add-api-claim.md). * Database type - * Entando recommends standardizing your choice of database to simplify operational maintenance but you do have the ability to use different databases for different microservices. - * Supported choices are none, MySQL, and Postgres. Enterprise customers can choose Oracle but should contact Entando Support for details. + * Entando recommends standardizing your choice of database to simplify operational maintenance, but you do have the ability to use different databases for different microservices. + * Supported choices are none, embedded, MySQL, and Postgres. Enterprise customers can choose Oracle but should contact Entando Support for details. * Development databases - * You can choose to utilize a full RDBMS or developers can utilize lightweight in memory or on disk databases with h2. + * You can choose to utilize a full RDBMS or developers can utilize lightweight in-memory or on-disk databases with H2. * Caching implementation - * When generating a microservice you will be presented with the type of cache to inject into the services. It is recommended that this is a standard choice for all of the microservices in your application but can be customized on a per service basis if desired. + * When generating a microservice, you will be presented with the types of cache to inject into the services. It is recommended that the type be uniform for all microservices in your application, but it can be customized on a per-service basis if desired. * Build system - * Determines the java build tool to use when building your services - * Supports maven or gradle + * Determines the Java build tool to use when building your services + * Supports Maven or Gradle * Other technologies - * Users of the component generator can also decide to use other technologies from JHipster or from the JHipster marketplace. - * There are many powerful technologies in the marketplace but it is up to the developer to integrate any choices from the marketplace into their Entando application. Entando doesn't provide any direct support for marketplace tech choices. + * Users of the Component Generator can also decide to use other technologies from JHipster or the JHipster marketplace. + * There are many powerful technologies in the marketplace but it is up to the developer to integrate the chosen technology into their Entando Application. Entando doesn't provide direct support for marketplace tech choices. * Micro frontends - * Users can optionally choose to generate micro frontends for entities generated via the blueprint. + * Optionally, users can choose to generate micro frontends for entities generated via the blueprint. * The Entando Component Generator only provides micro frontends in React from the generation flow but developers can create and bundle micro frontends using other technologies as well. ## Next Steps diff --git a/vuepress/docs/next/docs/reference/deployment-structure.md b/vuepress/docs/next/docs/reference/deployment-structure.md index 289fdfaf32..0bc8b3e0c8 100644 --- a/vuepress/docs/next/docs/reference/deployment-structure.md +++ b/vuepress/docs/next/docs/reference/deployment-structure.md @@ -7,15 +7,14 @@ sidebarDepth: 2 This page provides an overview of the key Entando GitHub repositories with brief descriptions of how these repositories are realized in a running Entando deployment. It also explores the architecture behind the Entando Platform and how its functions are structured. -## entando-operator -The Entando Operator coordinates the installation and configuration of all the components in an Entando -cluster. The operator can be installed once per cluster and is used to coordinate the plugin lifecycle for multiple Entando Applications across many namespaces. +## Entando Operator +The **Entando Operator** coordinates the installation and configuration of all of the components of an Entando Application. * GitHub: * DockerHub: #### Customization -Use existing [Entando Custom Resources](../consume/custom-resources.md) to extend the Entando Platform. +Use the [Entando custom resources](../consume/custom-resources.md) to extend the platform. ## Database Init Containers During installation, an Entando Application needs to create and initialize several databases when deploying from a backup of your images. @@ -40,7 +39,7 @@ The init containers automatically restore a backup included in your application ## entando-de-app -The **entando-de-app** is a J2EE application and an instance of the [**entando-core**](#entando-core). It provides pathways for other Entando Components and the server image the Entando Operator requires to manage the deployment. The pom.xml for the application reveals its dependencies. +The **entando-de-app** is a J2EE application and an instance of the [entando-core](#entando-core). It provides pathways for Entando Components and the server image required by the Entando Operator to manage the deployment. The pom.xml for the application reveals its dependencies. * GitHub: * DockerHub: , @@ -51,37 +50,35 @@ A customized image can include: * New APIs * Legacy Entando plugins * New database tables -* Other extensions to the **entando-core** +* Other extensions to the `entando-core` -It is recommended that most extensions to the Entando Platform occur in microservices. However, legacy +In most cases, microservices should be used to extend the platform. However, legacy integrations, extensions to the CMS, and migrations from earlier Entando versions may require changes to the **entando-de-app**. ## App Builder -The App Builder is the user-friendly frontend UI for the **entando-de-app**. A ReactJS application, it is served via node in the default deployment. In a quickstart deployment, the App Builder container is deployed in the **entando-app** multi-container pod. It communicates with the **entando-de-app** and the Entando Component Manager (ECM) via [REST -APIs](../consume/entando-apis.md). The ECM provides information about bundles deployed to the Local Hub. +The **App Builder** is the user-friendly frontend UI for the `entando-de-app`. A ReactJS application, it is served via Node in the default deployment. It communicates with the `entando-de-app` and the Entando Component Manager via [REST +APIs](../consume/entando-apis.md). The Component Manager provides information about bundles deployed to the Local Hub. * GitHub: * DockerHub: #### Customization -The App Builder is customized as part of many Entando implementations. -It can be customized at runtime via micro frontends -[widget configuration](../../tutorials/create/mfe/widget-configuration.md). +The **App Builder** is customized as part of many Entando implementations. +It can be customized via [configuration micro frontends](../../tutorials/create/mfe/widget-configuration.md) and [Entando Platform Capabilities (EPCs)](../../tutorials/create/mfe/epc.md). -## Entando Component Manager (ECM) -The ECM provides the link between the **entando-de-app**, or your custom core instance, and the ECR. The ECM queries the Entando Kubernetes service to fetch available +## Entando Component Manager +The **Entando Component Manager** provides the link between the `entando-de-app`, or your custom core instance, and the Local Hub. It queries the Entando Kubernetes service to fetch available bundles that have been deployed as custom resources inside the cluster. -The ECM also manages relationships between an Entando Application and the -installed plugins. This can be seen in the plugin link custom resource in Kubernetes. +The **Component Manager** also administers the relationships between an Entando Application and the +installed plugins. This is seen in the plugin link custom resource in Kubernetes. * GitHub: * DockerHub: ## entando-k8s-service -The **entando-k8s-service** acts as an abstraction layer to fetch data from Kubernetes APIs. Its primary -function is to discover and make available Entando plugins for installation. The -**entando-k8s-service** is invoked by the ECM. +The **entando-k8s-service** acts as an abstraction layer to fetch data from Kubernetes APIs. It interacts with the Local Hub to show the available bundles, installs and manages microservice plugins, and +monitors the status of the installed EntandoApp. * GitHub: * DockerHub: @@ -99,16 +96,15 @@ The Keycloak image can be customized as part of an Entando implementation. Some ## Other Key Repositories ### entando-core -The **entando-core** project is a J2EE application that exposes APIs for the Entando CMS, including the admin console and the portal UI project that performs the server side composition for pages rendered via an Entando Application. Note that only the composition is performed server side. JavaScript code is rendered client-side. The **entando-core** is realized via an instance that includes the -WAR files generated from a core build as dependencies. In a default deployment, this is the **entando-de-app**. +The **entando-core** project is a J2EE application that exposes APIs for the Entando CMS, including the Admin Console and the Portal UI project that performs the server-side composition for pages rendered via an Entando Application. Note that only the composition is performed server-side. JavaScript code is rendered client-side. The **entando-core** is realized via an instance that includes the WAR files as dependencies, which are generated from the core build. In a default deployment, this is the `entando-de-app`. * GitHub: -* DockerHub: None (deployed to maven central) +* DockerHub: None (deployed to Maven Central) #### Customization For users familiar with versions prior to Entando 6, there will be cases where the **entando-core** is customized. -Often, these customizations will be delivered via a WAR overlay in the instance project. -Using a WAR overlay is a functional approach for users already familiar with the process, but it is highly +Often, these customizations will be delivered via a WAR overlay in the project instance. +Using a WAR overlay is a functional approach for users familiar with the process, but it is highly recommended to extend the platform using microservices for new projects. ### entando-cms @@ -119,14 +115,13 @@ App Builder at build time and is included in the default deployment of the App B #### Customization In some cases, the **entando-cms** may be customized if new custom features are added to CMS-specific -functionality. However, most cases will use the more general App Builder extension points noted above. The **entando-cms** does not expose any dedicated extension interfaces outside of those already provided by the App Builder. +functionality. However, most cases will use the more general App Builder extension points noted above. ### Entando Kubernetes Controllers -There are a number of controllers that are available to the Entando Operator to manage installations and -components in an Entando cluster. These are small and lightweight images that execute as -run-to-completion pods, managing the installation flow for different parts of the infrastructure. The -controllers are implemented using Quarkus. For more information on the controllers, Entando custom -resources, and configuring your Entando deployment, see also: +A number of controllers are available to the Entando Operator to manage installations and +components in an Entando Cluster. These are small and lightweight images that execute as +run-to-completion pods, managing the installation flow for different parts of the infrastructure. For more information on controllers, Entando custom +resources, and configuring your deployment, see [Custom Resources](../consume/custom-resources.md). GitHub: diff --git a/vuepress/docs/v7.1/docs/create/component-gen-tech.md b/vuepress/docs/v7.1/docs/create/component-gen-tech.md index 587a17d9d0..f8959abef1 100644 --- a/vuepress/docs/v7.1/docs/create/component-gen-tech.md +++ b/vuepress/docs/v7.1/docs/create/component-gen-tech.md @@ -1,27 +1,33 @@ # Component Generation Technologies -When generating a microservice using the Entando Component Generator there are a number of technical choices that need to be made +When generating a microservice or micro frontend using the Entando Component Generator, there are a number of technical choices that need to be made: * Microservice code - * If you're interested in using Quarkus in your Entando app, contact us on the [Forum](https://forum.entando.org/) or [Community Slack](https://join.slack.com/t/entandocommunity/shared_invite/zt-g609owdv-2K~YRh8zrI6lqlWo4aFWUw) and we'll help you get started. - * If you're considering non-Java based microservices, [here is a definition of an Entando plugin](../curate/bundle-details.md#microservices-specifications), including information on the runtime contract required to use them. + * If you're considering microservices that are not based on Java, here are the [specifications of an Entando microservice](../curate/bundle-details.md#microservices-specifications), including information on the runtime contract required to use them. + * For a JavaScript example, see the Node.js microservice in the [API claim tutorial](../../tutorials/create/ms/add-api-claim.md). * Database type - * Entando recommends standardizing your choice of database to simplify operational maintenance but you do have the ability to use different databases for different microservices. - * Supported choices are none, MySQL, and Postgres. Enterprise customers can choose Oracle but should contact Entando Support for details. + * Entando recommends standardizing your choice of database to simplify operational maintenance, but you do have the ability to use different databases for different microservices. + * Supported choices are none, embedded, MySQL, and Postgres. Enterprise customers can choose Oracle but should contact Entando Support for details. * Development databases - * You can choose to utilize a full RDBMS or developers can utilize lightweight in memory or on disk databases with h2. + * You can choose to utilize a full RDBMS or developers can utilize lightweight in-memory or on-disk databases with H2. * Caching implementation - * When generating a microservice you will be presented with the type of cache to inject into the services. It is recommended that this is a standard choice for all of the microservices in your application but can be customized on a per service basis if desired. + * When generating a microservice, you will be presented with the types of cache to inject into the services. It is recommended that the type be uniform for all microservices in your application, but it can be customized on a per-service basis if desired. * Build system - * Determines the java build tool to use when building your services - * Supports maven or gradle + * Determines the Java build tool to use when building your services + * Supports Maven or Gradle * Other technologies - * Users of the component generator can also decide to use other technologies from JHipster or from the JHipster marketplace. - * There are many powerful technologies in the marketplace but it is up to the developer to integrate any choices from the marketplace into their Entando application. Entando doesn't provide any direct support for marketplace tech choices. + * Users of the Component Generator can also decide to use other technologies from JHipster or the JHipster marketplace. + * There are many powerful technologies in the marketplace but it is up to the developer to integrate the chosen technology into their Entando Application. Entando doesn't provide direct support for marketplace tech choices. * Micro frontends - * Users can optionally choose to generate micro frontends for entities generated via the blueprint. + * Optionally, users can choose to generate micro frontends for entities generated via the blueprint. * The Entando Component Generator only provides micro frontends in React from the generation flow but developers can create and bundle micro frontends using other technologies as well. -If you want to try out these choices follow the tutorial on [creating Entando microservices and micro frontends using the component generator](../../tutorials/create/ms/generate-microservices-and-micro-frontends.md). +## Next Steps + +- [Create microservices and micro frontends using the Entando Component Generator](../../tutorials/create/ms/generate-microservices-and-micro-frontends.md) +- [Create a React micro frontend](../../tutorials/create/mfe/react.md) +- [Create an Angular micro frontend](../../tutorials/create/mfe/angular.md) +- [Create a microservice, then an API claim with which a micro frontend can call it](../../tutorials/create/ms/add-api-claim.md) + diff --git a/vuepress/docs/v7.1/docs/reference/deployment-structure.md b/vuepress/docs/v7.1/docs/reference/deployment-structure.md index 289fdfaf32..0bc8b3e0c8 100644 --- a/vuepress/docs/v7.1/docs/reference/deployment-structure.md +++ b/vuepress/docs/v7.1/docs/reference/deployment-structure.md @@ -7,15 +7,14 @@ sidebarDepth: 2 This page provides an overview of the key Entando GitHub repositories with brief descriptions of how these repositories are realized in a running Entando deployment. It also explores the architecture behind the Entando Platform and how its functions are structured. -## entando-operator -The Entando Operator coordinates the installation and configuration of all the components in an Entando -cluster. The operator can be installed once per cluster and is used to coordinate the plugin lifecycle for multiple Entando Applications across many namespaces. +## Entando Operator +The **Entando Operator** coordinates the installation and configuration of all of the components of an Entando Application. * GitHub: * DockerHub: #### Customization -Use existing [Entando Custom Resources](../consume/custom-resources.md) to extend the Entando Platform. +Use the [Entando custom resources](../consume/custom-resources.md) to extend the platform. ## Database Init Containers During installation, an Entando Application needs to create and initialize several databases when deploying from a backup of your images. @@ -40,7 +39,7 @@ The init containers automatically restore a backup included in your application ## entando-de-app -The **entando-de-app** is a J2EE application and an instance of the [**entando-core**](#entando-core). It provides pathways for other Entando Components and the server image the Entando Operator requires to manage the deployment. The pom.xml for the application reveals its dependencies. +The **entando-de-app** is a J2EE application and an instance of the [entando-core](#entando-core). It provides pathways for Entando Components and the server image required by the Entando Operator to manage the deployment. The pom.xml for the application reveals its dependencies. * GitHub: * DockerHub: , @@ -51,37 +50,35 @@ A customized image can include: * New APIs * Legacy Entando plugins * New database tables -* Other extensions to the **entando-core** +* Other extensions to the `entando-core` -It is recommended that most extensions to the Entando Platform occur in microservices. However, legacy +In most cases, microservices should be used to extend the platform. However, legacy integrations, extensions to the CMS, and migrations from earlier Entando versions may require changes to the **entando-de-app**. ## App Builder -The App Builder is the user-friendly frontend UI for the **entando-de-app**. A ReactJS application, it is served via node in the default deployment. In a quickstart deployment, the App Builder container is deployed in the **entando-app** multi-container pod. It communicates with the **entando-de-app** and the Entando Component Manager (ECM) via [REST -APIs](../consume/entando-apis.md). The ECM provides information about bundles deployed to the Local Hub. +The **App Builder** is the user-friendly frontend UI for the `entando-de-app`. A ReactJS application, it is served via Node in the default deployment. It communicates with the `entando-de-app` and the Entando Component Manager via [REST +APIs](../consume/entando-apis.md). The Component Manager provides information about bundles deployed to the Local Hub. * GitHub: * DockerHub: #### Customization -The App Builder is customized as part of many Entando implementations. -It can be customized at runtime via micro frontends -[widget configuration](../../tutorials/create/mfe/widget-configuration.md). +The **App Builder** is customized as part of many Entando implementations. +It can be customized via [configuration micro frontends](../../tutorials/create/mfe/widget-configuration.md) and [Entando Platform Capabilities (EPCs)](../../tutorials/create/mfe/epc.md). -## Entando Component Manager (ECM) -The ECM provides the link between the **entando-de-app**, or your custom core instance, and the ECR. The ECM queries the Entando Kubernetes service to fetch available +## Entando Component Manager +The **Entando Component Manager** provides the link between the `entando-de-app`, or your custom core instance, and the Local Hub. It queries the Entando Kubernetes service to fetch available bundles that have been deployed as custom resources inside the cluster. -The ECM also manages relationships between an Entando Application and the -installed plugins. This can be seen in the plugin link custom resource in Kubernetes. +The **Component Manager** also administers the relationships between an Entando Application and the +installed plugins. This is seen in the plugin link custom resource in Kubernetes. * GitHub: * DockerHub: ## entando-k8s-service -The **entando-k8s-service** acts as an abstraction layer to fetch data from Kubernetes APIs. Its primary -function is to discover and make available Entando plugins for installation. The -**entando-k8s-service** is invoked by the ECM. +The **entando-k8s-service** acts as an abstraction layer to fetch data from Kubernetes APIs. It interacts with the Local Hub to show the available bundles, installs and manages microservice plugins, and +monitors the status of the installed EntandoApp. * GitHub: * DockerHub: @@ -99,16 +96,15 @@ The Keycloak image can be customized as part of an Entando implementation. Some ## Other Key Repositories ### entando-core -The **entando-core** project is a J2EE application that exposes APIs for the Entando CMS, including the admin console and the portal UI project that performs the server side composition for pages rendered via an Entando Application. Note that only the composition is performed server side. JavaScript code is rendered client-side. The **entando-core** is realized via an instance that includes the -WAR files generated from a core build as dependencies. In a default deployment, this is the **entando-de-app**. +The **entando-core** project is a J2EE application that exposes APIs for the Entando CMS, including the Admin Console and the Portal UI project that performs the server-side composition for pages rendered via an Entando Application. Note that only the composition is performed server-side. JavaScript code is rendered client-side. The **entando-core** is realized via an instance that includes the WAR files as dependencies, which are generated from the core build. In a default deployment, this is the `entando-de-app`. * GitHub: -* DockerHub: None (deployed to maven central) +* DockerHub: None (deployed to Maven Central) #### Customization For users familiar with versions prior to Entando 6, there will be cases where the **entando-core** is customized. -Often, these customizations will be delivered via a WAR overlay in the instance project. -Using a WAR overlay is a functional approach for users already familiar with the process, but it is highly +Often, these customizations will be delivered via a WAR overlay in the project instance. +Using a WAR overlay is a functional approach for users familiar with the process, but it is highly recommended to extend the platform using microservices for new projects. ### entando-cms @@ -119,14 +115,13 @@ App Builder at build time and is included in the default deployment of the App B #### Customization In some cases, the **entando-cms** may be customized if new custom features are added to CMS-specific -functionality. However, most cases will use the more general App Builder extension points noted above. The **entando-cms** does not expose any dedicated extension interfaces outside of those already provided by the App Builder. +functionality. However, most cases will use the more general App Builder extension points noted above. ### Entando Kubernetes Controllers -There are a number of controllers that are available to the Entando Operator to manage installations and -components in an Entando cluster. These are small and lightweight images that execute as -run-to-completion pods, managing the installation flow for different parts of the infrastructure. The -controllers are implemented using Quarkus. For more information on the controllers, Entando custom -resources, and configuring your Entando deployment, see also: +A number of controllers are available to the Entando Operator to manage installations and +components in an Entando Cluster. These are small and lightweight images that execute as +run-to-completion pods, managing the installation flow for different parts of the infrastructure. For more information on controllers, Entando custom +resources, and configuring your deployment, see [Custom Resources](../consume/custom-resources.md). GitHub: