nginxstatic-sitewebsecuritykrakend

KrakenD as a Proxy for Nginx Frontend


I've been exploring the possibility of using Krakend as a proxy for my Nginx frontend, and I'd like to share my experience and gather some insights from the community.

Here's the setup:

  1. I have a Spring Boot server serving as an API.
  2. There's a static site hosted on Nginx, both running within a VM.
  3. Krakend is running on a separate VM, acting as an API manager for the Spring Boot server.

Currently, I've configured Krakend to proxy requests to the static site using the following configuration:

{
  "endpoint": "/",
  "output_encoding": "no-op",
  "backend": [
    {
      "encoding": "no-op",
      "url_pattern": "",
      "sd": "static",
      "host": [
        "http://172.22.11.62"
      ],
      "disable_host_sanitize": false
    }
  ]
}

However, I'm encountering a couple of issues:

  1. When accessing "/", it redirects to auth/signin?redirectTo=%2F.
  2. I need to explicitly declare other routes of the static site along with parameters.

I'm wondering:

  1. Can Krakend act purely as a proxy without any manipulation, allowing seamless routing to the Nginx frontend?
  2. What are the best practices for configuring Krakend in this scenario?
  3. Is it recommended to use Krakend as a proxy for an Nginx frontend, or are there better alternatives?

Solution

  • KrakenD CE requires explicit declaration of all routes, which can be managed more efficiently with Flexible Configuration. This feature allows for dynamic updates to your configuration based on variables defining your internal routes. You can find more details here: https://www.krakend.io/docs/configuration/flexible-config/

    For seamless routing and handling of unspecified paths, the wildcard and catch-all endpoints features of the KrakenD Enterprise Edition would be ideal. These allow KrakenD to act more flexibly as a proxy, fitting scenarios like yours better.

    In any case, our best practice recommendation is to explicitly declare routes for clearer API contracts and granular management at the gateway level, even when using more dynamic features.