The NodeChef proxies, at least 3 connected to an app at any point in time recieves incomming request from your clients,
terminates SSL and forwards the request to your app containers. The proxies are written in C++ and easily handles more than 30k concurrent requests
per node. Our monitoring system automatically detects apps which exceed the capacity of the 3 proxies at any point in time and attaches new proxies
automatically to your App. Note, this only works if you setup your DNS using a CNAME pointing to the NodeChef subdomain assigned to your app.
Declarative features
It is possible to control URL mapping, 302 redirects , and 301 hostname redirects directly from the proxy without having to hardcode them into your App.
You can access this feature from the Task manager by clicking on App actions → Routing.
- Url Pathname routing
Allows for routing a request to another pathname. For example, you can route any request for the pathname "/" to "index.html" or landing page static asset. The proxy will send
the request to your app container using the "/index.html" path instead of the recieved "/". Note, routing does not perform a redirection. Also REGEX
for more advanced URL mapping is currently not supported but planned for release in the future
-
302 Pathname redirection
Allows for redirecting a request to another URL. On the dashboard, the attribute name specifies the path to redirect and the value of the attribute specifies the new url to redirect to. Redirects are served using 302 Found HTTP status code
-
301 Hostname redirection
Allows for redirect the incoming request using the value supplied in the host header.
For example, you can redirect all requests with the hostname "example.com" to "www.example.com"
-
Request forwarding
Forward request to another container/deployment. For example you can forward all request starting with /engineering to your
eng.nodechef.com deployment. This feature is suitable when you want to maintain the same host name but forward the request to a different service based on the path of the incomming request.
- An example starts with rule: /api*. The * character at the end indicates all paths that start with /api
- An example ends with rule: */api. The * character at the start indicates all paths that ends with /api
- An example index of rule: */api*. The * character both at the start and end indicates all paths that contain the string /api
- An example equals to rule: /api. Will match all request where the path is equal to /api