Caching kroki svgs

[regevbr]

When using kroki to generate umls in markdown, every page loads calls the kroki api which is redundant and time consuming.
@NGPixel do you think that inlining the resulting svg on render will give better performance?
If the answer is yes, I'm willing to create a pr!

[twoi]

@regevbr

When using kroki to generate umls in markdown, every page loads calls the kroki api which is redundant and time consuming.

But is this really true? When checking plantuml, I found it sets these headers:

Cache-Control: public, max-age=432000
Expires: [ 5 days from now ]

And my browser respects them, and consults the cache - so the problem you are describing does not exist as far as I can tell.

[twoi]

@regevbr

Your feature is useful for me for a different reason however: When plantuml / kroki rendering is requested by the server, rather than the client, I don't need to expose my plantuml / kroki servers to the internet. That way I don't need to figure out how to do authentication for those.

[regevbr]

@twoi you are correct when you look at it from a single client point of view, but there is no need to slow down the first page view for every client who access the page and to create that load on the rendering service...
About authentication, indeed that is also an added bonus

[twoi]

The only problem is that in contrast to rendering, while editing a plantuml diagram on a page, a hard-coded plantuml server will be used, leaking potentially private data to https://plantuml.requarks.io (perhaps that was the whole point of wiki.js ;-)

Described here: #3583

So once this is fixed and the configured plantuml server gets used for editing as well (in that case presumably called from the browser), I would need to expose the server on the internet...

[regevbr]

Seems like you need to express your valid concerns on your mentioned discussion wo they can address it in the pr there