Open borekb opened 2 years ago
Hi @borekb,
Thanks for your kind words abour Kroki! π€
If I understand correctly, the hosted kroki.io doesn't persist any data β in only uses compute (VMs by Exoscale) but there's no long-term storage of any data. This means that the entire diagram has to fit into the URL, via deflate + base64 as described in the README.
That's correct.
I wonder if you would consider Excalidraw-like approach which uses a clever technique:
This is a good idea and something I've considered but I'm relunctant to persist data (even if they are uncrypted). And to be completely honest, if we end up providing this feature it will most likely require a subscription. Why? Because we are now responsible for the data privacy/security and backup/recovery which come at a cost.
I understand that Kroki.io is simpler when it doesn't need to worry about data persistence but I hope that this example shows that the benefits of Excalidraw-like approach are substantial.
I'm fully aware of the benefits of such solution but also its constraints π
If we want to provide a good user experience, we would probably need a diagram editor where we would be able to "save" a diagram using a shorter URL. We could even use a user-defined name (i.e., https://img.krokio.io/borekb/client-server.svg
). Lot of exciting possibilities but we are now talking about a fullblown product that requires funding.
The question is, are users willing to pay a subscription fee to get such features? So far I've been fortunate enough to get Exoscale support but it does not cover all expenses.
Having said that, anyone can implement/provide this feature on top of Kroki.
BTW a practical limit for URL length seems to be only around 2000 characters / 2kB, probably a bit more in modern scenarios but it's still way too little for powerful diagramming tools like Excalidraw or draw.io/diagrams.net (which is not currently implemented but would be super-nice if it was, and there's an issue for it: #405).
Yes, the max URL length is a well-know limitation (described in the documentation: https://docs.kroki.io/kroki/setup/configuration/#_max_uri_length).
Thanks for the response, I realize it would be quite a big change for the infrastructure / hosting and fair enough if this is too much for Kroki.
I had this idea in mind for the setup:
You're right that anyone can build this on top of Kroki but I personally don't have the time right now (and in the near future), however, I'd be happy to sponsor a service that results from that, as in to cover the monthly costs. If this is something you'd like to discuss, feel free to reach me privately at borekb@gmail.com.
You're right that anyone can build this on top of Kroki but I personally don't have the time right now (and in the near future)
Me neither, I don't have time in the near future to take on this effort.
however, I'd be happy to sponsor a service that results from that, as in to cover the monthly costs. If this is something you'd like to discuss, feel free to reach me privately at borekb@gmail.com.
Thanks, I will keep that in mind ππ»
I didn't mention it but another workaround is to use a POST request: https://docs.kroki.io/kroki/setup/usage/#_post_requests
From a privacy and IP point of view, the use case of Kroki not persisting data is very strong too. Having Kroki persist anything at all would make it a problem for many users and in many organizations this would shut down the discussion about using it.
That Kroki is able to be deployed in containers locally, with no external traffic, is a great architectural decision and its implementation has made using diagrams-as-text exceeding useful.
That said, the idea of persistence in the way you described is appreciated.
Hi, I've recently came across this amazing π service, it's so nice that I don't need to install all the tools locally!
If I understand correctly, the hosted https://kroki.io/ doesn't persist any data β in only uses compute (VMs by Exoscale) but there's no long-term storage of any data. This means that the entire diagram has to fit into the URL, via deflate + base64 as described in the README.
I wonder if you would consider Excalidraw-like approach which uses a clever technique:
excalidraw.com/#json=...
This means that Excalidraw URLs are fixed width regardless of diagram complexity:
For comparison, here is the same scenes via Kroki:
I understand that Kroki.io is simpler when it doesn't need to worry about data persistence but I hope that this example shows that the benefits of Excalidraw-like approach are substantial.
BTW a practical limit for URL length seems to be only around 2000 characters / 2kB, probably a bit more in modern scenarios but it's still way too little for powerful diagramming tools like Excalidraw or draw.io/diagrams.net (which is not currently implemented but would be super-nice if it was, and there's an issue for it: https://github.com/yuzutech/kroki/issues/405).