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. You set up and use portal in two broad ways, as a backend and frontend.

  • First, as a backend collection of Gloo custom resources that you use to configure your developer portal. These resources include the portal, as well as the apps, route tables, and policies that you use to direct traffic to your APIs.
  • Second, as the frontend developer portal that your end users interact with to access your APIs. By default, Gloo provides a demo React app with API docs for basic functionality such as generating API keys and logging in. Then, you can integrate or customize the app with your own branding and API information.
Figure: Portal setup overview
Figure: Portal setup overview
Figure: Portal setup overview
Figure: Portal setup overview
  1. As the Gloo Platform administrator, you install the required components to run Portal. For more information, see Administer Portal.
  2. As the app owner, you deploy OpenAPI apps across clusters or even workspaces. Then, you bundle the apps together by creating a route table for all the apps that you want to expose through the developer portal. You might think of this route table of apps as your API product. Create a route table for each version of your app, with its own lifecycle management, terms of service, and other metadata. Then, you can group separate route table versions together into a single API product to display in the developer portal to your end users.For more information, see Create your API products.
  3. As the portal admin, you make sure that the virtual gateway is set up with the host that your portal listens on, which matches the host in the route table. Then, you can create a usage plan to control access to your API product by combining two types of policies: rate limiting and external auth. Finally, you include all these details in the Portal custom resource. For more information, see the following guides:
  4. As the frontend developer, you can apply your company’s branding to the developer portal. This setup also includes the way that end users interact with your API, such as generating API keys for accessing or the API docs for using your API product. For more information, see Build a developer portal frontend.
  5. Your end users interact with your APIs through the developer portal. For more information, see Interact with the developer portal.