December 2024 Summaries

CEL interpolation support has been extended to the URL field in the forward-internal action, allowing dynamic routing based on request attributes like URL, host, and headers. This capability enables the redirection of requests to different internal endpoints by extracting elements such as subdomains from the request host variable, thereby simplifying complex workflows like site-to-site connectivity without the need for VPNs. Practical applications include dynamically routing traffic to customer networks or developer machines using unique subdomains and custom headers, streamlining the management of numerous endpoints. Organizations can use CEL interpolation to connect SaaS applications directly to customer networks or direct requests to individual developer environments, enhancing flexibility and efficiency in traffic management. The documentation provides further insights into CEL interpolation, encouraging users to explore its potential and share their use cases through community channels.

API gateways, while evolving from reverse proxies or load balancers to handle more complex business logic, often face challenges related to observability due to their dependency on specific environments and processes. This limitation frequently arises because extracting and utilizing observability data is not straightforward, requiring complex deployments of additional infrastructure such as Prometheus and Grafana. Consequently, developers are often left to manage intricate systems and incur substantial costs in both time and resources. Furthermore, many API gateways do not seamlessly integrate with existing development tools, complicating efforts to test and debug in environments that mimic production settings. Observability platforms themselves may also lack prioritization of vital debugging tools, such as request replays, that are crucial for diagnosing and resolving issues effectively. Despite these challenges, there are solutions like ngrok's API gateway that aim to simplify the process by providing full request observability data without requiring new instrumentation, ensuring operational consistency across environments and enabling efficient debugging through request replays.

When releasing the `Traffic Policy` feature at the beginning of the year, it was noticed that configuring it with the agent or SDKs had a "papercut" due to its highly typed and structured policy configuration requirements. To address this, the design was updated to use strings instead of typed structures for policy configurations, making it easier to configure correctly and reducing maintenance and breakage issues. The new string format allows for more flexibility and consistency in configuring traffic policies, while still supporting older configurations through server-side validation.

The text explores the challenges and solutions in managing API gateways, emphasizing the balance between infrastructure control and developer flexibility. Typically, infrastructure teams maintain the security and resiliency of the API "front door," but this can lead to inflexibility for developers who need to make changes, often resulting in frustration and bottlenecks. The text introduces ngrok's API gateway as a solution that allows infrastructure teams to control security measures while enabling developers to self-service and manage their own API functionalities behind the "front door" without compromising security. This is achieved through a composable architecture using internal and cloud endpoints, where Traffic Policy rules can be applied at different stages of a request's lifecycle. This setup allows infrastructure engineers to maintain high-level control and security, while developers can independently manage and optimize their APIs, fostering a collaborative environment that enhances maintainability, flexibility, and efficiency in API management.

Ngrok has introduced a new Traffic Policy variable called conn.server_region, which allows users to make decisions based on the region from which traffic originates, enhancing the ability to manage API requests more efficiently than using country code lists. This feature was developed in response to customer feedback and is intended to simplify the process of routing traffic by region, reducing complexity and improving maintainability. The global server load balancer (GSLB) automatically routes requests to the nearest Point of Presence (PoP) based on latency, and the new capability enables users to define specific actions for traffic based on server regions. This includes forwarding requests to regional endpoints, automating failover processes, and ensuring compliance by controlling cross-region traffic. Ngrok emphasizes the ease of implementing this feature through a few lines of YAML, reflecting their commitment to customer-driven development and simplifying networking challenges for API gateway users.

Ngrok has introduced a new Traffic Policy action called verify-webhook, designed to authenticate webhook requests sent to HTTP endpoints, ensuring they originate from the correct provider and are intended for the correct recipient. This action supports over 50 popular webhook providers and uses cryptographic verification logic tailored to each provider to validate requests. Users can securely store webhook verification keys in encrypted vaults, and the secrets.get() macro dynamically retrieves these secrets at runtime, enhancing security by keeping sensitive values out of policy YAML files. The verify-webhook action can be integrated into Traffic Policy rules to protect applications from unauthorized access, forged requests, and various attacks such as replay attacks. This action allows developers to integrate webhooks safely without writing custom verification code and supports a wide range of configurations, including conditional logic and combining with other Traffic Policy actions. The introduction of this action also offers features like inspecting, replaying, and evaluating logged webhook requests, providing a comprehensive solution for secure webhook management within the ngrok platform.