7 Jul 2023
Discover the advanced support for additional API types in Gloo Platform, with a special focus on GraphQL. Unlike traditional pass-through proxies, Gloo Platform offers a unique approach by providing a fully integrated GraphQL server built in C++ and seamlessly integrated with Envoy Proxy.
Experience the power of Gloo Platform's GraphQL capabilities as we explore its features. We start with an existing REST API, a Blog service, and showcase the transformation of this API into a GraphQL API using declarative configuration. No coding is required as Gloo Platform handles the mapping and transformation automatically.
During the demonstration, we dive into the configuration, including the schema definition language (SDL) that defines the GraphQL schema. The power of Gloo Platform becomes evident when we examine the resolvers, which automatically map the existing REST API to the GraphQL schema. This transformation is encapsulated in a route table, a familiar concept within Gloo Platform.
With the configuration in place, we witness the appearance of the GraphQL API in the Gloo Platform UI. The API registry provides a comprehensive view of the schema, including queries and entities. For seamless exploration and interactive query building, we utilize GraphiQL, an intuitive tool that enables us to access and retrieve data from the GraphQL API.
But Gloo Platform doesn't stop at transforming a single API type. It offers the ability to aggregate multiple API types, such as REST and gRPC, into a unified GraphQL API. By adding an additional upstream REST API and annotating it with a resolver, we demonstrate the combination of data sources within the GraphQL server.
This demonstration merely scratches the surface of the powerful capabilities Gloo Platform offers for GraphQL. Explore the endless possibilities and unlock the potential of GraphQL in your API ecosystem with Gloo Platform.
Stay tuned for more content and innovative solutions from Gloo Platform.
Experience the power of Gloo Platform's GraphQL capabilities as we explore its features. We start with an existing REST API, a Blog service, and showcase the transformation of this API into a GraphQL API using declarative configuration. No coding is required as Gloo Platform handles the mapping and transformation automatically.
During the demonstration, we dive into the configuration, including the schema definition language (SDL) that defines the GraphQL schema. The power of Gloo Platform becomes evident when we examine the resolvers, which automatically map the existing REST API to the GraphQL schema. This transformation is encapsulated in a route table, a familiar concept within Gloo Platform.
With the configuration in place, we witness the appearance of the GraphQL API in the Gloo Platform UI. The API registry provides a comprehensive view of the schema, including queries and entities. For seamless exploration and interactive query building, we utilize GraphiQL, an intuitive tool that enables us to access and retrieve data from the GraphQL API.
But Gloo Platform doesn't stop at transforming a single API type. It offers the ability to aggregate multiple API types, such as REST and gRPC, into a unified GraphQL API. By adding an additional upstream REST API and annotating it with a resolver, we demonstrate the combination of data sources within the GraphQL server.
This demonstration merely scratches the surface of the powerful capabilities Gloo Platform offers for GraphQL. Explore the endless possibilities and unlock the potential of GraphQL in your API ecosystem with Gloo Platform.
Stay tuned for more content and innovative solutions from Gloo Platform.
- 1 participant
- 5 minutes
7 Jul 2023
Discover how Gloo Platform can implement a service mesh zero trust architecture in this demonstration. We explore three components: a server API representing a protected service, a client API with legitimate access needs, and a bad actor exploiting traditional controls.
Initially, we observe the service mesh without access controls in place. Active network traffic flows without encryption, authentication, or authorization. Both the client API and the bad actor access sensitive data owned by the server API without restrictions.
Next, we apply a Gloo Platform access policy to secure the API. The policy enforces strict mutual TLS (mTLS) for access and specifies the allowed principles, in this case, the ZTA client API.
After applying the policy, we re-examine the traffic. The line between the client API and the server API is still green, indicating successful communication. However, it now features an mTLS lock icon, signifying encryption, strong identity for authentication and authorization. The bad actor encounters a red line, representing intercepted and denied requests by Gloo Platform.
To summarize, we transform an initially unsecured API into a secure one through Gloo Platform's access policy. The bad actor is denied access, while the legitimate client API communicates with the server API securely, employing encryption, authentication, and authorization using a robust mTLS identity.
Experience the power of Gloo Platform in implementing a service mesh zero trust architecture. Stay tuned for more informative content.
Initially, we observe the service mesh without access controls in place. Active network traffic flows without encryption, authentication, or authorization. Both the client API and the bad actor access sensitive data owned by the server API without restrictions.
Next, we apply a Gloo Platform access policy to secure the API. The policy enforces strict mutual TLS (mTLS) for access and specifies the allowed principles, in this case, the ZTA client API.
After applying the policy, we re-examine the traffic. The line between the client API and the server API is still green, indicating successful communication. However, it now features an mTLS lock icon, signifying encryption, strong identity for authentication and authorization. The bad actor encounters a red line, representing intercepted and denied requests by Gloo Platform.
To summarize, we transform an initially unsecured API into a secure one through Gloo Platform's access policy. The bad actor is denied access, while the legitimate client API communicates with the server API securely, employing encryption, authentication, and authorization using a robust mTLS identity.
Experience the power of Gloo Platform in implementing a service mesh zero trust architecture. Stay tuned for more informative content.
- 1 participant
- 4 minutes
7 Jul 2023
Welcome to an exciting demonstration of Gloo Platform Portal's ability to support multiple logical portals, catering to different tenants. In this video, we'll walk you through the process of managing and targeting APIs within these portals.
As you can see, we have two portals deployed in Gloo Platform Portal. The first portal includes two APIs: the Catstronauts API and the Petstore API. On the other hand, the second portal currently doesn't have any APIs deployed. The APIs associated with each portal are selected based on their labels. In this case, we have a "partner dev portal" label and a "dev portal" label.
To showcase the flexibility of Gloo Platform Portal, let's move the Petstore API from one portal to the other. We can achieve this by simply changing the label of the corresponding API product. Once we make the label change, we add it to the Git repository, commit the changes, and push them. Leveraging the power of Argo CD CI/CD pipeline, we apply this update to our Petstore API product.
Upon synchronization with the cluster, we can observe that the Petstore API product has been removed from one portal. Upon refreshing the page, we witness the Petstore API being seamlessly picked up by the other portal, now catering to different tenants and effectively targeting a new audience.
Prepare to be amazed by the versatility and adaptability of Gloo Platform Portal, as it effortlessly handles multiple logical portals, delivering tailored experiences to different tenants. Stay tuned for more powerful demonstrations and transformative features.
As you can see, we have two portals deployed in Gloo Platform Portal. The first portal includes two APIs: the Catstronauts API and the Petstore API. On the other hand, the second portal currently doesn't have any APIs deployed. The APIs associated with each portal are selected based on their labels. In this case, we have a "partner dev portal" label and a "dev portal" label.
To showcase the flexibility of Gloo Platform Portal, let's move the Petstore API from one portal to the other. We can achieve this by simply changing the label of the corresponding API product. Once we make the label change, we add it to the Git repository, commit the changes, and push them. Leveraging the power of Argo CD CI/CD pipeline, we apply this update to our Petstore API product.
Upon synchronization with the cluster, we can observe that the Petstore API product has been removed from one portal. Upon refreshing the page, we witness the Petstore API being seamlessly picked up by the other portal, now catering to different tenants and effectively targeting a new audience.
Prepare to be amazed by the versatility and adaptability of Gloo Platform Portal, as it effortlessly handles multiple logical portals, delivering tailored experiences to different tenants. Stay tuned for more powerful demonstrations and transformative features.
- 1 participant
- 2 minutes
7 Jul 2023
Get ready to witness the true power of Gloo Platform's multi-cluster, multi-cloud capabilities. In this example, we'll demonstrate how Gloo Platform seamlessly operates in a diverse environment consisting of an AWS management cluster, a Gloo workload cluster in AWS, and another workload cluster in GCP. By leveraging this setup, we'll deploy a Gloo Platform Portal in AWS, along with API products in both AWS and GCP, showcasing how Gloo Platform can unify these different API products from different clusters into a single, cohesive development portal.
As we dive into the demonstration, let's explore the Gloo Platform Dashboard, where we can witness the presence of two clusters within our environment. Cluster one represents an AWS Elastic Kubernetes Service (EKS) cluster, while cluster two corresponds to a Google Kubernetes Engine (GKE) cluster running in Google Cloud. Additionally, we've deployed a developer portal in cluster one, our AWS environment.
When we navigate to the Developer Portal UI, the gateway to our portal, we discover the availability of two remarkable API products: the Catstronauts REST API and the Petstore REST API. By exploring the portal, we can examine the open API specifications of both API products, utilizing either the Redoc or Swagger view. This gives us a comprehensive understanding of the capabilities and functionalities provided by each API.
Now, returning to the Gloo Platform Dashboard, we shift our focus to the APIs section. Here, we observe that the Catstronauts REST API is deployed in cluster one, our AWS environment. On the other hand, the Petstore REST API API product is deployed in cluster two, residing within the Google Cloud ecosystem.
What makes this demonstration truly remarkable is that, despite the deployment of our API products across multiple clusters and clouds, Gloo Platform Portal's multi-cluster and multi-cloud design allows us to utilize a single development portal as a unified window for managing all our API products across various environments.
Prepare to be amazed by Gloo Platform's exceptional capabilities in a multi-cluster, multi-cloud environment. Stay tuned for more demonstrations and powerful features.
As we dive into the demonstration, let's explore the Gloo Platform Dashboard, where we can witness the presence of two clusters within our environment. Cluster one represents an AWS Elastic Kubernetes Service (EKS) cluster, while cluster two corresponds to a Google Kubernetes Engine (GKE) cluster running in Google Cloud. Additionally, we've deployed a developer portal in cluster one, our AWS environment.
When we navigate to the Developer Portal UI, the gateway to our portal, we discover the availability of two remarkable API products: the Catstronauts REST API and the Petstore REST API. By exploring the portal, we can examine the open API specifications of both API products, utilizing either the Redoc or Swagger view. This gives us a comprehensive understanding of the capabilities and functionalities provided by each API.
Now, returning to the Gloo Platform Dashboard, we shift our focus to the APIs section. Here, we observe that the Catstronauts REST API is deployed in cluster one, our AWS environment. On the other hand, the Petstore REST API API product is deployed in cluster two, residing within the Google Cloud ecosystem.
What makes this demonstration truly remarkable is that, despite the deployment of our API products across multiple clusters and clouds, Gloo Platform Portal's multi-cluster and multi-cloud design allows us to utilize a single development portal as a unified window for managing all our API products across various environments.
Prepare to be amazed by Gloo Platform's exceptional capabilities in a multi-cluster, multi-cloud environment. Stay tuned for more demonstrations and powerful features.
- 1 participant
- 2 minutes
7 Jul 2023
In this video, we will showcase how our platform empowers you to efficiently manage your APIs and API products in a Kubernetes and cloud native environment.
To begin, we'll explore a Kubernetes deployment and service that deploys a microservice with a specific API. By leveraging our Gloo annotations, we enable the platform to automatically discover the microservice's OpenAPI specification. Initially, the Kubernetes platform does not have any API documentation available. However, once we deploy our servers and deployments, the platform seamlessly discovers the OpenAPI specification. We can view the complete OpenAPI spec in the Kubernetes custom resource.
Now, we can proceed to deploy our API products using route tables in Gloo Platform Portal. A route table defines the API product, including labels, portal metadata, such as the API title, description, terms of service, contacts, licenses, and more. It also specifies the destination service that implements the API. Upon applying the API product route table, we can see the deployed API in our developer portal, which provides a comprehensive interface. Additionally, the Gloo Platform dashboard showcases the API, its OpenAPI specification, and the JSON schema format.
In the developer portal's frontend UI, which is built using React, we can explore the API product, in this case, the Catstronaut API. It is presented in both Redoc and Swagger views, allowing users to choose their preferred documentation style. We can seamlessly switch between views and utilize the "try-it-out" functionality provided by the platform. Upon execution, we receive a 200 response from the API product we deployed.
To enhance security, we decide to change the API visibility to private, requiring users to log in to access it. By defining a portal group that grants access based on specific claims, we can control the visibility of the API. Applying the portal group allows users with the "users" claim and value to access the API labeled as "tracks" (our customer's API).
Next, we focus on securing our API product through API key authentication and authorization. This involves applying an Auth policy to routes with the label "usage plan Dev portal." Our "tracks" API has the "Dev portal" usage plan, enabling us to enforce API key requirements. We also apply a rate limit policy to control the number of requests per second, minute, or hour that can be sent to our API.
When we revisit our Catstronaut API in the Dev portal UI, we notice that access is now restricted. To generate an API key, we enable the usage plans in the Dev portal configuration. We define three usage plans: bronze, silver, and gold, which align with the rate limiting configuration. These plans encompass both rate limiting and API key authentication. In the Dev portal UI, we can see the three usage plans, and we generate a new API key called "my key." After pasting the API key into the Swagger view, we can access the API and receive a 200 response. However, when the rate limit is exceeded, we receive a 429 "too many requests" response.
Furthermore, we demonstrate the cloud native approach of deploying additional API products using Argo CD and a CI/CD pipeline. We synchronize the Helm chart of a pet store API product with our cluster using Argo CD, resulting in the deployment of the parts, deployments, services, and the API product in the Dev portal. While the Petstore API initially includes only the "paths" API, we introduce two more microservices: the user API and the store API. By adding their OpenAPI specifications to our route table API products, we combine the APIs of these microservices into a single Petstore API product.
To manage the Dev portal configuration and usage plans efficiently, we utilize CI/CD pipelines and GitOps approaches. This allows development and platform teams to control and automate the deployment of APIs, API products, and the Dev portal's configuration. We showcase this by adding a new usage plan called "Platinum" to the Dev portal and rate limit server configuration. Through GitOps and synchronization with the Git repository, the changes are instantly applied, providing an initial usage plan for deployed API products on the dashboard.
Thank you for joining us in this demo of Gloo Platform Portal, where managing your APIs and API products in a Kubernetes and cloud native environment becomes streamlined and efficient. Don't forget to like, share, and subscribe to our channel for more content!
To begin, we'll explore a Kubernetes deployment and service that deploys a microservice with a specific API. By leveraging our Gloo annotations, we enable the platform to automatically discover the microservice's OpenAPI specification. Initially, the Kubernetes platform does not have any API documentation available. However, once we deploy our servers and deployments, the platform seamlessly discovers the OpenAPI specification. We can view the complete OpenAPI spec in the Kubernetes custom resource.
Now, we can proceed to deploy our API products using route tables in Gloo Platform Portal. A route table defines the API product, including labels, portal metadata, such as the API title, description, terms of service, contacts, licenses, and more. It also specifies the destination service that implements the API. Upon applying the API product route table, we can see the deployed API in our developer portal, which provides a comprehensive interface. Additionally, the Gloo Platform dashboard showcases the API, its OpenAPI specification, and the JSON schema format.
In the developer portal's frontend UI, which is built using React, we can explore the API product, in this case, the Catstronaut API. It is presented in both Redoc and Swagger views, allowing users to choose their preferred documentation style. We can seamlessly switch between views and utilize the "try-it-out" functionality provided by the platform. Upon execution, we receive a 200 response from the API product we deployed.
To enhance security, we decide to change the API visibility to private, requiring users to log in to access it. By defining a portal group that grants access based on specific claims, we can control the visibility of the API. Applying the portal group allows users with the "users" claim and value to access the API labeled as "tracks" (our customer's API).
Next, we focus on securing our API product through API key authentication and authorization. This involves applying an Auth policy to routes with the label "usage plan Dev portal." Our "tracks" API has the "Dev portal" usage plan, enabling us to enforce API key requirements. We also apply a rate limit policy to control the number of requests per second, minute, or hour that can be sent to our API.
When we revisit our Catstronaut API in the Dev portal UI, we notice that access is now restricted. To generate an API key, we enable the usage plans in the Dev portal configuration. We define three usage plans: bronze, silver, and gold, which align with the rate limiting configuration. These plans encompass both rate limiting and API key authentication. In the Dev portal UI, we can see the three usage plans, and we generate a new API key called "my key." After pasting the API key into the Swagger view, we can access the API and receive a 200 response. However, when the rate limit is exceeded, we receive a 429 "too many requests" response.
Furthermore, we demonstrate the cloud native approach of deploying additional API products using Argo CD and a CI/CD pipeline. We synchronize the Helm chart of a pet store API product with our cluster using Argo CD, resulting in the deployment of the parts, deployments, services, and the API product in the Dev portal. While the Petstore API initially includes only the "paths" API, we introduce two more microservices: the user API and the store API. By adding their OpenAPI specifications to our route table API products, we combine the APIs of these microservices into a single Petstore API product.
To manage the Dev portal configuration and usage plans efficiently, we utilize CI/CD pipelines and GitOps approaches. This allows development and platform teams to control and automate the deployment of APIs, API products, and the Dev portal's configuration. We showcase this by adding a new usage plan called "Platinum" to the Dev portal and rate limit server configuration. Through GitOps and synchronization with the Git repository, the changes are instantly applied, providing an initial usage plan for deployed API products on the dashboard.
Thank you for joining us in this demo of Gloo Platform Portal, where managing your APIs and API products in a Kubernetes and cloud native environment becomes streamlined and efficient. Don't forget to like, share, and subscribe to our channel for more content!
- 1 participant
- 10 minutes
7 Jul 2023
Welcome to a demonstration of the powerful analytics feature in Gloo Platform Portal API. In this video, we'll showcase how this feature provides valuable insights into API usage.
Our platform's analytics workflow begins when a user or system accesses an API using an API key. The API Gateway, which is an Envoy proxy, validates the API key and verifies authorization for API access. During this validation process, we retrieve additional metadata related to the API key, such as the attached usage plan. This information is then stored in the access log of our API Gateway.
To harness the power of analytics, we employ an open telemetry pipeline to fetch data from the access log. This data is processed within our OTEL (OpenTelemetry) pipeline and stored in one of the supported data stores. In this demonstration, we utilize ClickHouse as the data store for the API access log. The stored data includes requests, response validity, API product access, specific API access details, usage plans, API keys, and more.
By leveraging ClickHouse as a data source, we can visualize the API usage information through a Grafana dashboard. This dynamic dashboard allows us to select the desired product and view usage information based on various parameters. We can choose the usage plan, request URL, HTTP method, response status code, and even filter by user ID. This enables us to analyze request latency, track status codes over time, and identify top API consumers for a specific API.
Furthermore, the dashboard allows us to focus on individual API users by selecting their user IDs. We can examine up to 100 user IDs, matching the top API consumers. Additionally, if we wish to explore the usage of a specific user, we can easily apply a filter based on the username or a partial match. This provides comprehensive insights into total API calls made, status codes over time, request latency, and more.
Apart from the overall API product usage and analytics dashboard, Gloo Platform Portal offers out-of-the-box dashboards for each API product. These dedicated dashboards provide focused information for specific API products or allow users access to relevant analytics for their respective products.
It's worth mentioning that our open telemetry pipeline allows data export to any data store supported by OpenTelemetry. This means the data utilized in our API product usage and analytics dashboard can be exported to other environments for further processing. This opens up exciting possibilities for implementing use cases like API usage monetization and advanced analytics.
Prepare to dive into a world of actionable insights as we explore the API usage analytics capabilities of Gloo Platform Portal. Stay tuned for more features and demonstrations!
Our platform's analytics workflow begins when a user or system accesses an API using an API key. The API Gateway, which is an Envoy proxy, validates the API key and verifies authorization for API access. During this validation process, we retrieve additional metadata related to the API key, such as the attached usage plan. This information is then stored in the access log of our API Gateway.
To harness the power of analytics, we employ an open telemetry pipeline to fetch data from the access log. This data is processed within our OTEL (OpenTelemetry) pipeline and stored in one of the supported data stores. In this demonstration, we utilize ClickHouse as the data store for the API access log. The stored data includes requests, response validity, API product access, specific API access details, usage plans, API keys, and more.
By leveraging ClickHouse as a data source, we can visualize the API usage information through a Grafana dashboard. This dynamic dashboard allows us to select the desired product and view usage information based on various parameters. We can choose the usage plan, request URL, HTTP method, response status code, and even filter by user ID. This enables us to analyze request latency, track status codes over time, and identify top API consumers for a specific API.
Furthermore, the dashboard allows us to focus on individual API users by selecting their user IDs. We can examine up to 100 user IDs, matching the top API consumers. Additionally, if we wish to explore the usage of a specific user, we can easily apply a filter based on the username or a partial match. This provides comprehensive insights into total API calls made, status codes over time, request latency, and more.
Apart from the overall API product usage and analytics dashboard, Gloo Platform Portal offers out-of-the-box dashboards for each API product. These dedicated dashboards provide focused information for specific API products or allow users access to relevant analytics for their respective products.
It's worth mentioning that our open telemetry pipeline allows data export to any data store supported by OpenTelemetry. This means the data utilized in our API product usage and analytics dashboard can be exported to other environments for further processing. This opens up exciting possibilities for implementing use cases like API usage monetization and advanced analytics.
Prepare to dive into a world of actionable insights as we explore the API usage analytics capabilities of Gloo Platform Portal. Stay tuned for more features and demonstrations!
- 1 participant
- 4 minutes
8 Sep 2021
Amazon EKS Anywhere (EKS-A) works better with Istio service meshes and Envoy Proxy API gateways to connect applications and microservices in hybrid Kubernetes (K8s) environments. Solo's Gloo Mesh and Gloo Edge can help!
Read more: https://www.solo.io/blog/amazon-eks-anywhere-and-solo-istio/
#EKSAnywhere #K8s #Kubernetes #Microservices #istio
Read more: https://www.solo.io/blog/amazon-eks-anywhere-and-solo-istio/
#EKSAnywhere #K8s #Kubernetes #Microservices #istio
- 1 participant
- 5 minutes
8 Sep 2021
Amazon EKS Anywhere (EKS-A) works best with an Envoy Proxy API gateway to manage and secure connections to your applications at the edge. Solo's Gloo Edge solves this need.
Learn more: https://www.solo.io/blog/eks-a-and-envoy-proxy/
Learn more: https://www.solo.io/blog/eks-a-and-envoy-proxy/
- 1 participant
- 19 minutes
22 Jul 2021
A quick demo of core Gloo Edge features. Gloo Edge builds on open source Envoy Proxy to make Kubernetes-native API gateways more secure, more reliable, and easier to manage. Gloo Edge receives requests from clients, and manages ingress by applying your routing rules and filters on traffic. It enforces zero-trust security and can handle high availability, load balancing, and failover. Gloo Edge also discovers upstream resources, defines your policies, and gives you visibility for troubleshooting and audits. WebAssembly lets you do advanced customization of your filters.
- 1 participant
- 9 minutes
22 Jul 2021
A quick demo of core Gloo Portal features. Gloo Portal is an advanced, database-less API developer portal built for Istio and Envoy Proxy. Fully integrated with Gloo Mesh Enterprise and Gloo Edge Enterprise, the portal abstracts the complexity and enables developers to publish, document, share, discover, and use APIs with rich controls, detailed configuration information, and comprehensive security. You can define application policies that affect the service mesh itself, including access, routes, policies, and configurations, making self-service a reality. Gloo Portal improves API-producer and -consumer developer productivity for both Kubernetes and traditional environments.
- 1 participant
- 13 minutes
25 Jun 2021
A quick demo of key Gloo Mesh features. Gloo Mesh builds on open source Istio to make service meshes more secure, more reliable, and easier to manage. Gloo Mesh can discover services, coordinate service meshes, configure and observe behavior, federate policies everywhere, and enforce security consistently.
- 1 participant
- 7 minutes
