Question: any option to define wildcard in endpoints?

[bsctl]

Hello, first of all it's an amazing project!
Any option to setup a wildcard in endpoints preserving the structure? For example, I want forward
http://krakend:8000/myserviceA/humans/man/user?userId={id} http://krakend:8000/myserviceA/animals/dogs/dog?dogId={id} http://krakend:8000/myserviceA/animals/cats/cat?catId={id}

to the backend http://serverA/ preserving the structure of the paths above, i.e
http://serverA/humans/man/user?userId={id} http://serverA/myserviceA/animals/dogs/dog?dogId={id} http://serverA/myserviceA/animals/cats/cat?catId={id}

On the other hands, I want to forward

http://krakend:8000/myserviceB/humans/man/user?userId={id} http://krakend:8000/myserviceB/animals/dogs/dog?dogId={id} http://krakend:8000/myserviceB/animals/cats/cat?catId={id}

to the backend http://serverB/ preserving the same structure.

Something like this:

        {
          "endpoint": "/myserviceA/*",
          "backend": [
            {
              "host": [ "http://serverA/" ],
              "url_pattern": "/"
            }
          ]
        },
        {
          "endpoint": "/myserviceB/*",
          "backend": [
            {
              "host": [ "http://localhost:8060" ],
              "url_pattern": "/"
            }
          ]
        }

O something similar. Any idea?
Thanks

[kpacha]

Hi, @Kalise

if you know the pattern of your URL structure/strategy, you can use regular URL params. Following your example, you could use this config:

{
  "endpoint": "/myserviceA/{level1}/{level2}/{level3}",
  "backend": [
    {
      "host": [ "http://serverA/" ],
      "url_pattern": "/{level1}/{level2}/{level3}"
    }
  ]
},
{
  "endpoint": "/myserviceB/{level1}/{level2}/{level3}",
  "backend": [
    {
      "host": [ "http://localhost:8060" ],
      "url_pattern": "/{level1}/{level2}/{level3}"
    }
  ]
}

and the querystring params will be passed too

EDIT: this proposed solution is also not supported by the gin router. gin-gonic/gin#1681

[bsctl]

Thanks @kpacha,
but this is not my case. The structure of the endpoints {level1}/{level2}/{level3}/...{levelN} has potentially hundreds of children and it is dynamically populated by the target server. My use case is to put an APIs gateway in front of multiple Kubernetes APIs Servers.

Any option to have Krakend supporting wildcards * in endpoints and url patterns?

[kpacha]

We avoided supporting wildcards because the way we understand the API Gateway pattern and its differences with a pure L7 router. As discussed on the post what is an api gateway:

The API gateway is a way to solve the problem of how clients consume their use-cases in a microservice-based ecosystem within the microservice pattern

and

1- By definition, an API Gateway should not be a single entry point in a microservice ecosystem as it would enforce centralization, coordination and have a single point of failure. The API gateway should be the entry point to some set of use cases, and you should analyze how to group these use cases in different API gateway services. As with any other microservice, the scope of the service matters. Otherwise we are moving the monolith from the API to the gateway!

2- Proxying is not in the scope of the API gateway layer, because it means clients are totally coupled to the service implementation rather than to the use case they are trying to cover. There were tons of good proxies out there before the microservice pattern was popular and they solve a very different problem.

If you are looking just for routing the requests and responses on an url-pattern basis, without any further manipulation, maybe you need a pure kubernetes proxy.

cheers!

[bsctl]

@kpacha Thanks for your answer.

[aserrallerios]

Sorry for asking, but has this been reconsidered?

That blog post says that we shouldn't put cross-cutting concerns on an Api Gateway (like token validation) IF we're not adapting and decoupling the contract of the microservices, if I understand correctly.

Adapting contracts and cross-cutting concerns are two different things, but KrakenD decided to support both. Why not just offer the full toolbox to developers only interested in cross-cutting concerns for a given endpoint?

[kpacha]

hi @aserrallerios ,

in order to keep the issues as clean as possible, I'd suggest you to join the krakend channel at the gopher's slack.

Here, the invite link: https://invite.slack.golangbridge.org/

[github-actions]

This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.