-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENDOC-524 7.1 Ent CLI-create new API management page #540
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,89 @@ | ||
--- | ||
sidebarDepth: 1 | ||
--- | ||
|
||
|
||
# Overview | ||
|
||
An API claim informs the Entando Platform that a micro frontend (MFE) intends to use the API of a microservice (MS). This request can be sent within a single bundle or across bundles. The abstraction of an API claim eliminates the need to define and manage API endpoints, both in local development and within a running instance. | ||
|
||
## Internal vs. External API Claim | ||
|
||
An MFE can initiate both internal and external API claims. An internal claim specifies an MS API in the same bundle as the MFE, while an external claim specifies the MS API of another bundle in the same Kubernetes namespace. | ||
|
||
The structure of internal and external API claims are as follows: | ||
|
||
**Internal API claim** | ||
``` json | ||
{ | ||
"name": "int-api", | ||
"type": "internal", | ||
"serviceName": "int-ms" | ||
} | ||
``` | ||
**External API claim** | ||
``` json | ||
{ | ||
"name": "ext-api", | ||
"type": "external", | ||
"serviceName": "ext-ms", | ||
"bundle": "registry.hub.docker.com/my-org/my-entando-bundle" | ||
} | ||
``` | ||
|
||
## API Claim Commands | ||
|
||
Common operations associated with API claims are detailed below. To execute `ent bundle api` subcommands, the user must be connected to a running Entando instance (via `ent attach-*`) or the CLI will generate an authentication error. | ||
|
||
| Command | Description | ||
| :- | :- | ||
| `ent bundle api add [mfe-name] [claim-name]` | Add an internal API claim to an MFE | ||
| `ent bundle api add-ext [mfe-name] [claim-name]` | Add an external API claim to an MFE | ||
| `ent bundle api rm [mfe-name] [claim-name]` | Remove an API claim from an MFE | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would also add a note about the fact that all There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jyunmitch Minor, might be better to write |
||
|
||
**Command details:** | ||
- `api add` supports the following options: | ||
- `service-name`: The name of a microservice in the same bundle as the micro frontend | ||
- `service-url`: The URL of a microservice deployed in the local environment | ||
|
||
- `api add-ext` supports the following options: | ||
- `bundle`: The external bundle URL | ||
- `service-name`: The name of a microservice in the external bundle. If `service-name` is not set, `api add-ext` will initiate an interactive mode where the user can select from available bundles and microservices. | ||
|
||
- `api add-ext` requirements: | ||
- Connection to an Entando instance | ||
- The cluster contains the service specified in the API claim | ||
- The external service has already been deployed | ||
|
||
- Executing `api add-ext` without flags: | ||
- Returns the current instance | ||
- Displays the instance's available services for interactive selection | ||
|
||
## Microservice URL Retrieval | ||
|
||
To render an MFE installed from a bundle, Entando injects a JSON object containing configuration details inside the "config" attribute of a custom HTML element, e.g. `<my-mfe config="{ ... }" />`. | ||
|
||
**Installed Bundles** | ||
|
||
To retrieve the URL of an MS declared through an API claim, add `systemParams.api[claimName].url` to the MFE JavaScript code so it can access that element of the config object. The `claimName` was chosen by the user when the API claim was defined. | ||
|
||
Refer to the Entando demo bundles for alternative retrieval methods that are more robust and consider cases where the parent object is not defined. | ||
|
||
**Local Bundles** | ||
|
||
When testing an MFE locally, the MS URL can be retrieved from the `mfe-config.json` file in the "public" MFE folder, e.g: | ||
``` | ||
{ | ||
"systemParams": { | ||
"api": { | ||
"my-api-claim": { | ||
"url": "http://localhost:8082" | ||
} | ||
} | ||
} | ||
} | ||
``` | ||
|
||
This file is not used outside of local testing. The configuration data of installed bundles are provided by the Entando instance. | ||
|
||
The commands that add and remove API claims update `mfe-config.json` automatically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open question: can this only reference other bundles within the same project/namespace? We might need @w-caffiero-entando to comment but "external" sounds like it could be external to this bundle (as it appears) or external to this project/namespace - say to other projects or even outside kubernetes to other enterprise systems or even to external 3rd party services in the cloud. Based on the format of the bundles I suspect it's only the first case but we should probably add a clarifying note on the scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this context
external
means external to the bundle, but not to the Kubernetes namespace. Indeed, when you executeent bundle api add-ext
you have to be connected to an Entando instance and the command will fail if it sees that the service you are specifying in the API claim doesn't exist on the cluster. The external service has to be deployed before adding its API claim.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you execute the command without the flags it searches the available services on the instance, so that you can select one of them interactively:

The command also displays that you are running it on a given instance.