Introspection of nats to configure and keep up to date the caddy config

[gedw99]

Hey @infogulch

I was wondering what you think about how we make it easy to keep nats configuration and caddy config in sync ?

I imagine that some parts of the caddy config are dependent on how we have nats setup , and I wanted to know what aspects you think are worth pursuing . The stream name is one obvious one ? But perhaps others are worth considering .

There is a way to ask nats its current configuration and then output caddy config fragments ( that are based on a simple template ) to update caddy config when nats changes . I like this simplicity, rather than using the caddy admin rest api , which tends to only like caddy json config .

Caddy -watch will then just automagically update caddy runtime.

Can be at runtime or design time .. the choice is ours.

just brain storming this one with you to see what your thoughts are .

[infogulch]

Hi Ged,

If I understand right, you want to dynamically configure Caddy (specifically the nats xtemplate provider) based on the live nats configuration.

I know you like the Caddyfile syntax (so do I), but caddy json is pretty good if you can tolerate the deep nesting. Your strategy of overwriting the Caddyfile and using caddy run --watch seems like it would work fine.

I guess I have a few questions about how this would work:

• What happens if nats is set up to have multiple streams? I think you still have to manually configure it to determine which stream to use.
• What do you mean by configuring at runtime or design time?

Sorry I took a while to respond. Have you already decided what to do?

[gedw99]

Hey

yes you understood the intent .

caddy json is, I agree , the only way , since caddy admin api spits back caddy json .

There are two schools on thought :

1. Regen the whole caddy json or

2. partials approach.

IMHO You actually need both . Just like a db is snapshotted and CDC.

answers:

1. steam represents a namespace . You ell the servers its namespace . So if you have 2 duplicate caddy servers geo locked they use the same stream .

but that’s not how I look at it . It’s better to think of it in terms of parametrics and CQRS.
so a caddy JSON file has a namespace and all json data for it is just the read side of the CQRS. The write side of the CQRS is the partials . The transformation from the see side changes into the read side is driven by any transform mapper . Benthos is kind of perfect for this . Here is an example : https://github.com/akhenakh/geo-benthos

2 . Is all runtime . Thee is no compile step in this system . So the templates are 100 % runtime

Do you get it ?

https://github.com/gedw99/goPocJsonSchemaForm Has elements of this way of thinking .

the html is runtime driven . JSON can also be generate this way . Htmx is used in it but that’s not what’s important here .

the jsonschema describes the data and the output . At runtime you can change it and the html or csddy json will change

[gedw99]

This jsonSchemaForm thing in my GitHub would pair really well with xtemplate.

As far as I know xtemplate has the routes stuff done for you, but not so much of the way the GUI looks.

The classic Master / Detail pattern is where jsonSchemaForm excels.

I am working on getting it working off SQLITE, so that Schema changes are detected at runtime and so the JSON Schema changes based on the DB Schema.

This is all just the same sort of CQRS Pattern in a way, just like how I brain stormed how to update the Caddy JSON config. You're watching the "write" side , and transforming, and create the "read" side.

For a DB is just CDC. For Caddy you can model it in a DB, and gen the new Caddy JSON.

By combining the jsonSchemaForm you now have a GUI to Modify the Caddy JSON.