Pluto.jl
Pluto.jl copied to clipboard
fonsp
What you see is what you REST
Watch the presentation!
https://www.youtube.com/watch?v=xsxJt4prFG4
Try it out!
julia> ]
pkg> activate --temp
pkg> add https://github.com/ctrekker/Pluto.jl#wysiwyr2
julia> import Pluto; Pluto.run()
Awesome!
With this, one could build powerful micro-services with very little effort. Thinking about use cases e.g. in financial industry, it would be important to protect the notebooks, so that the user of the API cannot modify the notebook (i.e. the running microservice) itself. For this, the following features would be great in my opinion:
- The notebook should define which variables are modifyable with the API and which variables should be requestable. Possible syntax:
@listen a, b
@publish y, z
Variables not explicitly defined should not be accessible from the API. Maybe the default could be to listen / publish all variables, unless @listen / @publish is explicitly written in the notebook?
- It should be possible to allow users access of the API without allowing them to open the notebook itself. This could e.g. be archieved by using different secrets.
Your first point makes a lot of sense! Not only would explicitly defining which variables users can change via the API (in production/deployment settings) enhance notebook protection, but it would also allow for further optimization since execution plans can be computed beforehand and only once.
For your second point, I was thinking about adding a configuration option which would allow users to run Pluto in an "API only" mode which would disable notebook editing and access features, restricting use to the API only. Perhaps this mode will also default to only serving "endpoints" defined by the @listen and @publish macros mentioned earlier and will otherwise fall back to serving all variables but give a warning message in the console about notebook security.
Would it be possible to put the functionality for accessing the Pluto REST API (in file REST.jl, like PlutoNotebook) into a separate little package, e.g. called PlutoRESTClient? When it is in Pluto, you have to import the complete Pluto package in your client just to use the REST API access functions.
@lungben It's definitely overkill to have to import all of Pluto, so putting it in a separate package that main Pluto would import inside PlutoRunner might work better. Perhaps the REST functions live in a different package, PlutoRESTClient.jl, and is exported from Pluto.jl as well?
+1 for a seperate package, I'd like to use this as a workspace backend for CLI scripts etc. too, see also #1073
The client functionality is now in a separate package https://github.com/JuliaPluto/PlutoRESTClient.jl. I haven't published it nor removed the client code from the PR yet though
