Add client/server support for all diagram types

[pepijnve]

Make it possible to run asciidoctor-diagram as a diagram generating web service. This would enable usage of the diagram extension in the browser for instance. Very similar to what https://github.com/eshepelyuk/asciidoctor-plantuml.js is already doing, but that only supports PlantUML since it uses the plantuml server directly.

[pepijnve]

Consider making the web service interface compatible with that of PlantUML (see http://plantuml.com/server). Having a service that offers a superset of the PlantUML service while also serving as a drop-in replacement for it could be useful. This would only support the rendering part of the PlantUML server.

PlantUML expects GET /<format>/<encoded> where

• format is one of png, svg or txt
• encoded is the base64 encoded, compressed diagram source. The data is either a deflate or brotli bitstream.

[mojavelinux]

Solving this would open up Asciidoctor Diagram to users of Antora, the browser extensions, and modern IDEs like Atom and VSCode. Since these tools use Asciidoctor.js, it currently puts Asciidoctor Diagram out of reach. If Asciidoctor Diagram could be used as a service, it would bridge the language gap and bring it back into play.

asciidoctor-plantuml.js is no doubt going to play an important role, but we know there are many more diagramming tools out there with which Asciidoctor Diagram integrates. So we can't stop at PlantUML. Being able to use Asciidoctor Diagram is vital for Asciidoctor users, regardless of the environment.

The API PlantUML exposes is a good start and certainly worth supporting for portability. But don't hold back if you need to introduce something more sophisticated.

[jagedn]

Hi

I'm playing with the idea and I've started a prototype that you can see in action at http://adoc-diagram.puravida-software.com:8080

This server accepts GET request following the pattern /diagram/{diagram-type}/{data64} and by the moment only generate a png image as response where:

• diagram-type can be ditaa or plantuml (no tested others)
• data64 is the body of the block

The backend is a micronaut app with asciidoctorj:1.5.6 + asciidoctorj-diagram:1.5.10 dependencies who try to build the adoc on the fly using the arguments and returns the image generated by the libraries

[mojavelinux]

To be compatible with the PlantUML HTTP API, perhaps consider /diagram/{type}/{format}/{data64} even if you only support png at the moment.

[jagedn]

good idea.

Also I moved the app to the port 80 ( http://adoc-diagram.puravida-software.com )

I was trying to include as many types I can but some of them are difficult to include, so by the moment the app can work with:

• ditaa
• graphviz
• plantuml
• nwdiag

I've created a docker version in case someone want to run it without the server at 'pvidasoftware/adoc-diagram'

[ggrossetie]

@jagedn Nice, is the code available on GitHub ?

[jagedn]

Hi,

the code is in Gitlab at https://gitlab.com/puravida-software/asciidiagram the documentation is at https://puravida-software.gitlab.io/asciidiagram and a live version is running at http://asciidiagram.puravida-software.com/

[pepijnve]

I'm not planning any further work on this. A rudimentary Sinatra app is available in lib/asciidoctor-diagram/http/server.rb; anything more sophisticated is covered by Kroki. Delegating rendering to a server has been delivered as well a while ago.