You mentioned something about deploying to gh-pages. But can that actually do any of the Julia parts, or would it just be a preview of the layout?
It just serves a copy of the front-end site to https://amellnik.github.io/JuliaAPIDemo/ so you can access it there instead of at localhost:4200
. However, thereās not much point in using it until we have a production back-end. You can use it to point at the development back-end running at localhost:7777
but this will throw an error at the moment because the back-end only works with http
and the front with https
(although I can set up the front end to do http
on one of my domains later today). You would also need to modify this line in srvr.jl
to accept connections from wherever the front-end is served from ā right now it assumes the development front-end.
Iām starting to look at setting up an AWS lambda or Heroku app that will run a production back-end now, but itās going to take a bit of doing, and unless someone beats me to it, I may not have it going until after the holidays.
Sounds great. I got the plot margins fixed up, so now itās looking great.
Iāll keep tweaking this, but we should take this to the issues on the repositories now. I think that the JuliaWebAPI is great and very easy to use. Iāll chat around and see if we can get any help hosting this, but please take your time: we are in no rush here (but it is super cool).
However, if others have alternative solutions, feel free to share.
Itās possible to use heroku:
https://github.com/pinx/heroku-buildpack-julia
There is also the Julia Openshift Cartridge:
https://github.com/codeneomatrix/julia-cartridge
Which is operating in this direction:
http://julia-tareaito.rhcloud.com/
I googled for status:
https://github.com/mdenchev/langlang/issues/1
Found also:
āHave you heard the good word? Rust can now target asm.js and WebAssembly (wasm) via
emscripten.ā [Note, below in Rust 1.14, said to be āexperimentalā.]
And; didnāt look into:
āEverything worksā
Rest is not directly related to [only[ web/Julia, just interesting, and might be an indirect way to target the web or compiling to assembly in general:
http://notes.willcrichton.net/rust-the-new-llvm/
āRust compiles to LLVMā [but stated other way around better] āRust in this kind of ecosystem offers five primary advantages over LLVM:ā
[and disadvanages]
ā2. The story for dynamic languages needs refinement. Specifically, it needs a battle-hardened GC (as far as I know, thereās really only one major attempt so far).ā [rust-gc]
āTo my knowledge, Lia is the first major language that actually compiles directly to Rust.ā
[competitor to Julia?]
āLia is a dynamically typed and garbage collected programming language that seamlessly interopts with Rust by using Rust as a compile target.ā
one advantage, not for webā¦, just released Rust 1.14 has over Julia (LLVM?):
āMIPS
and
s390x-unknown-linux-gnuā
Didnāt look into new MIR for Rust, or if itās an alternative compiler target:
Not sure what you mean, are you answering
-
as you want Julia compiled to JS, or just work in a browser? Escher already makes JS for you (you do not have to write it is CSS or HTML, as far as I understood). Itās just not arbitrary JS generated from Julia.
-
or asking about āserver backendā? It has that, but not a possibility of a separate, e.g. Apache as Genie.jl does.
The JS still has to be dynamically generated at the server and sent back.
For anyone who is curious about where this has ended up, hereās the application:
and hereās a blog post about it:
This is awesome, @ChrisRackauckas. Iāll definitely look back on this as a reference if I need to host Julia computation in the future. Thanks for the great project and writeup!
This is really good. Thank you.
Iād like however to add one perspective I suspect a lot of non-technical people would share:
Being able to build a webapp for your package is a very attractive feature. It would be very useful to have some bare-bones, ultra simple, dumbed-down tutorial that includes some but not all of the components from this project. Maybe a simple sin plot with some input from the user?
My point is that there are scores of scientists that built some cool package theyād like to share in the form of a webapp, but very few of them built a webapp before. They (read: me) donāt know much about the terminology and parts involved in building and deploying a webapp. While this project demonstrates how this can be done, its level of complexity prevents these users from replicating it.
Imagine a template where the user could just replace the sin function with her own, adding or subtracting simple features, and following dumbed-down instructions on how to deploy it all on some standard server (e.g. aws). THAT would elevate the functionality of this effort tremendously!
+1 to this. Itās the case for me as well but I guess itās pretty general in research environments. My overall feeling is that for simple stuff the (amazing) package Interact.jl can take care of all the interactivity, without needing to know anything about web programming (javascript html etcā¦). As soon as it gets more complicated than that itās not so clear how to proceed. Escher.jl seemed ideal but it doesnāt seem recommended anymore. I could really use a tutorial on ābuild a webapp for dummiesā.
Iāve been planning a package to do just this, and will try to have a minimal working package with a lot of documentation within the next week and a half. My eventual goal is that you should be able to call a single function like
microservice("my_fn", (x, y) -> x + 2*y)
and then be able to go to http://some.url/my_fn#?x=2?y=2 to get a JSON representation of the output. Doing this for base will be easy, but making it adaptable enough to work for arbitrary packages will be tricky.
Here is the example on the REPL using Bukdu.
To get the master branch by
Pkg.clone("https://github.com/wookay/Bukdu.jl")
julia> importall Bukdu
julia> type CalculateController <: ApplicationController
conn::Conn
end
julia> function my_fn(c::CalculateController)
q = c[:query_params]
x, y = map(v -> parse(Int, v), (q[:x], q[:y]))
render(JSON, x + 2*y)
end
my_fn (generic function with 1 method)
julia> Router() do
get("/my_fn", CalculateController, my_fn)
end
julia> Bukdu.start(8080)
INFO Listening on http://127.0.0.1:8080
Now you can request as
http://127.0.0.1:8080/my_fn?x=2&y=3
thanks.
Looks great!
I would like to see that example in the repo somewhere. From the repo example in the README, I cannot see how one would do such a request.
Bukdu can be deployed on Heroku. Go to the demo site (https://bukdu.herokuapp.com).
It would be more helpful to give a step by step for this. The deployment part is tricky, and you already found out how to do it!
Iām also looking for azure hosting instructions. Anyone know if the Data Science VM can be used out of the box for this purpose?
Iām thinking of a better way such as having conn::Conn
in the controller.
would you mind post an issue to the Bukdu repository.
thanks!
@yakir12 ā A general method of deploying an API from within a notebook or the REPL will take a while longer, but https://github.com/amellnik/JuliaHerokuEndpoint now has a minimal but functional example as well as fairly detailed descriptions. If you have any trouble or if the instructions are unclear at any point please file and issue there and I would be glad to help.
OMG, thank you! Awesome, Iāve booked off all next week to play around with this. Thanks!
Some very nice code and documentation in this thread.
For completeness, I will point out JuliaWebAPI.jl which allows you to expose any Julia function via ZMQ or HTTP transports. Itās a small but robust codebase, and has been used in production for many years.
Regards
Avik
This is awesome! Thanks again!