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

Proposal: define custom URL for functions #1082

alexellis opened this Issue Feb 9, 2019 · 0 comments


None yet
1 participant
Copy link

alexellis commented Feb 9, 2019

Expected Behaviour

Within the function definition we should provide an alternative configuration for when someone wants to serve a website or api from a function such as:

Imagine a microservice/function named giving-page

It would be exposed as per:

  • Optional user-friend URLs

If a user would like a more user-friendly or custom URL than what they currently have by default

  • Added security when managing / issuing cookies

Cookies issued to gw:port/function/name1 may also be accessible by gw:port/function/name2, by allowing custom domains we can have more separation at the domain level

  • Make this more streamlined / simple for users

User currently need to do this via an ingress path in Kubernetes or a custom configuration for their reverse proxy of choice.

This proposal would allow a custom domain to be routed such as:

The way we add arbitrary metadata to functions is via annotations, such as how we define topics for the connector SDK / triggers.

    image: ae/annotations:0.1

The gateway would look for a Host header, and if that matched a function queried via the /system/functions/ API (to be cached in-memory) then the traffic would be forwarded to the function using a proxy and any other gateway endpoints would not respond. i.e. you would not be able to call for instance or

A query and cache for /system/functions is already being built up and consumed when scale_from_zero is enabled on the gateway. It makes available a list of functions and how many readyReplicas they have. This could be extended, or a single mechanism could populate this cache and a second cache.

I don't think that multiple URLs (hosts) should be specified at this point, since they will point to the same function.

In production use, the user would still have to manage and configure DNS records and TLS certificates. This change would only be concerned with reverse-proxying requests to functions.

Current Behaviour

  • Define an ingress path pointing to the gateway.
  • Create a custom reverse-proxy rule i.e. in nginx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment