One of the unique features of Gloo Portal is its architecture. You can use the same Kubernetes and Gloo custom resources to design and secure your portal as you use for the rest of your setup. This flexible architecture lets you reuse existing configuration to manage all parts of your API microservices more consistently. Review the following demo setup and sample request flow diagrams to learn more about the Gloo Portal architecture.

Demo setup architecture

Review the following demo setup to understand more about the various resources that you create to put together a developer portal.

Figure: Demo setup resources
Demo setup resources
Figure: Demo setup resources
Demo setup resources

Example request flow

Review the following example request flow from an end user of the developer portal to your backing APIs.

Figure: Example request flow sequence diagram
Example request flow sequence diagram
Figure: Example request flow sequence diagram
Example request flow sequence diagram

Personas

Review the following diagram and explanation to understand how different personas can manage the lifecycle of your APIs with Gloo Portal.

Figure: Personas for managing APIs with Gloo Portal
Personas for managing APIs with Gloo Portal
Figure: Personas for managing APIs with Gloo Portal
Personas for managing APIs with Gloo Portal

  1. API developer: API developers create the APIs that you want to securely share through the developer portal. Specific tasks include:

    • Develop the apps with an OpenAPI spec (OAS) so that the apps can be shared through the developer portal.
    • Deploy the Kubernetes workloads and services for the apps. The API product owner makes sure that an ApiDoc gets created to represent the apps. For an example, see Deploy sample apps.

  2. API product owner: API product owners bundle several APIs together into a product for end users to consume. Their tasks include making sure that all of the relevant metadata to use the API products are configured:

    • Verify that the Kubernetes services that the API developers deployed have the appropriate, Solo-specific annotations so that ApiDocs are automatically created. If not, manually create ApiDocs. For an example, see Create ApiDocs.
    • Create ApiProducts that bundle together as many ApiDocs as you want to expose in the developer portal.
    • Add important metadata such as discrete versions, lifecycle status, and terms of service for the ApiProducts. For an example, see Create API products.

  3. Portal admin: Portal admins make sure that backend components are set up securely so that the user-facing developer portal works as intended. Their tasks span across many parts of Gloo Portal. For an example, see the Create a portal tutorial.

    • Set up routes to the ApiProducts so that their services can be reached externally.
    • Protect the ApiProducts with external auth and rate limiting policies.
    • Install Gloo Portal and related components, such as the external auth server, rate limiter, and any monitoring capabilities to track portal usage.
    • Create the backend Portal resource, including the routes to all of the ApiProducts to include in the Portal.
    • Deploy a frontend app that exposes the Portal externally as a developer portal.
    • Integrate Gloo Portal with an Identity Provider (IdP) so that users can self-service credentials.
    • In the developer portal, manage and approve any changes to the apps, teams, and users.

  4. API users: API users use the developer portal to securely access the ApiProducts that were set up. They take advantage of Gloo Portal’s self-service features:

    • Get the external link along with any self-service information about the developer portal from the Portal admins. For an example, see the End user guide.
    • Browse the ApiProducts that are exposed in the developer portal.
    • Subscribe to apps and teams in the developer portal.
    • Create their own credentials to ApiProducts based on the apps and teams that they are a part of.