We've put Julia and our package in a docker container and built a Ruby on Rails front end that spins up containers when needed. When we've needed to do a little more communication with the julia instance, we've run a ZMQ server in Julia and fed in the required data. (after poking open the ports through Docker) This has worked very well in that it allows Julia to do what it does best (numerical computation) and lets Rails and some other packages handle all the networking. Using this architecture we've been able to develop our julia package just as a command line app.
On Tuesday, June 16, 2015 at 11:35:40 AM UTC-4, Matthew Krick wrote: > > I've read everything I could on deployment options, but my head is still a > mess when it comes to all the choices, especially with how fast julia is > moving! I have a website on a node.js server & when the user inputs a list > of points, I want to solve a traveling salesman problem (running time > between 2 and 10 minutes, multiple users). Can someone offer some advice on > what's worked for them or any pros/cons to each option? Least cost is > preferable to performance. > > > 1. Spawn a new node.js instance & solve using node-julia ( > https://www.npmjs.com/package/node-julia) > 2. Use Forio's epicenter to host the code ( > http://forio.com/products/epicenter/) > 3. Create a julia HTTP server & make a REST API ( > https://github.com/JuliaWeb/HttpServer.jl) > 4. Host on Google Compute Engine (https://cloud.google.com/compute/) > 5. Host on Amazon's Simple Queue (http://aws.amazon.com/sqs/) > 6. Use Julia-box, if it can somehow accept inputs via an http call ( > https://www.juliabox.org/) > 7. ??? > > >
