Publishing to nats://

[samstride]

Hey Folks,

Great job on the API Gateway. We are a Golang + k8s dev shop and we have Kraken 1.2.0 and NATS setup on k8s.

Reading your docs, I got the impression that a Kraken endpoint can publish to a NATS subject directly. Is that understanding correct?

For instance, a frontend client can push events to a queue using a REST interface

Assuming I understood things correctly, I setup kraken config as follows:

"endpoints": [
        {
            "endpoint": "/publishtohello",
            "method": "POST",
            "backend": [
                {
                    "host": [
                        "nats://"
                    ],
                    "disable_host_sanitize": true,
                    "extra_config": {
                        "github.com/devopsfaith/krakend-pubsub/publisher": {
                            "topic_url": "hello"
                        }
                    }
                }
            ]
        }
    ],

and have the following env in k8s:

            env:
            - name: NATS_SERVER_URL
              value: "nats-server.nats:4222"

PS: I also tried specifying the env in the Dockerfile.

Now, I POST a message to <kraken_ip>/publishtohello.

curl --location --request POST '<kraken_ip>/publishtohello' \
--data-raw '{
    "message": "hello"
}'

I have a subscriber listening for messages on topic hello but nothing shows up.

Any idea what I got wrong?

Cheers.

[kpacha]

I'm not an expert on nats, but in my local env, this config works flawless

{
    "version": 2,
    "name": "My lovely gateway",
    "port": 8080,
    "timeout": "1s",
    "endpoints": [{
            "endpoint": "/",
            "method": "POST",
            "backend": [{
                "host": ["nats://"],
                "disable_host_sanitize": true,
                "extra_config": {
                    "github.com/devopsfaith/krakend-pubsub/publisher": {
                        "topic_url": "updates"
                    }
                }
            }]
        },
        {
            "endpoint": "/",
            "backend": [{
                "host": ["nats://"],
                "disable_host_sanitize": true,
                "extra_config": {
                    "github.com/devopsfaith/krakend-pubsub/subscriber": {
                        "subscription_url": "updates"
                    }
                }
            }]
        }
    ]
}

$ curl -id'{"foo":"bar"}' -H'Content-Type: application/json' localhost:8080/
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Krakend: Version 1.2.0
X-Krakend-Completed: false
Date: Thu, 08 Oct 2020 13:29:21 GMT
Content-Length: 4

null% 

$ curl -i localhost:8080
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Krakend: Version 1.2.0
X-Krakend-Completed: true
Date: Thu, 08 Oct 2020 13:29:27 GMT
Content-Length: 13

{"foo":"bar"}%

[samstride]

@kpacha, thanks for replying. I tried your config that has both publisher and subscriber and that worked for me.

After your config, I managed to find the issue.

NATS has nats (publish/subscribe) and nats streaming aka stan (publish/subscribe with durability).

Looks like KrakenD at this stage works with nats and not stan which is what we are using.

As an example, a nats connection using NATSs official go client looks like this:

import nats "github.com/nats-io/nats.go"

natsConnection, err := nats.Connect("nats://<URL>:4222")

A stan connection using NATSs official go client looks like this:

import stan "github.com/nats-io/stan.go"

stanConnection, err := stan.Connect("<name_of_stan_server>", "<unique-client-id>", stan.NatsURL("nats://<URL>:4222"))

I am happy for the issue to be closed and will keep an eye out for the stan implementation if that ever happens.

Thanks again.

[kpacha]

thanks to your comment, I found out that the nats adapter works under the umbrella of at-most-semantics while the stan client operates under the at-least-once semantics. That's not covered by the pub/sub package but I think it'd be interesting to include the exploration of such semantics into the project backlog.

cheers!

[github-actions[bot]]

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.