Hi, there.
I’m starting a new RESTful backend project and would love to use Julia to build it. The only things that are making me a little concerned are the stability and ability of HTTP.jl to handle multiple simultaneous requests. Can you tell me how is it going at this moment of Julia and HTTP.j maturity?
GraphQL would be a really good option, but Diana.jl doesn’t seem to be ready for heavy loads yet. Does anyone know anything about that?
I’ll be using containers and thought about the possibility of minimizing eventual overload problems by scaling them and/or the pods, but as it significantly affects the price, it would be nice to know how ready are these technologies to face big real world problems.
Thanks in advance! Your help would be really appreciated!
That should be completely fine. HTTP.jl can handle multiple simultaneous requests without problems.
However, given that you plan to use pods and containers, there is one issue which you will likely run in to: time to first response. Although Julia compilation keeps getting faster by optimizations in the core language and by optimizations of packages, the time to first response is longer than you would have in Go.
But, this of course, depends a bit on what you need. If you don’t mind that it takes pods a few seconds to minutes to start, then it’s all fine. Otherwise, you can try to reduce the time to first response via PackageCompiler.jl. A newer and even easier approach is via precompilation. It isn’t in the docs of SnoopCompile.jl yet, but there is an explanation by Tim Holy at Improve time-to-first-read via precompile + despecialization by quinnj · Pull Request #875 · JuliaData/CSV.jl · GitHub. Basically, with precompilation, Julia will precompile many core methods during package installation. So, if you do that inside a Docker build, then compilation should be quite fast for subsequent starts + runs of Julia, because the important execution paths are already compiled.
Thanks for the response, @rikh!
The first response is not a problem for now, but you’ve mentioned Go. That’s my first option in case I feel it’s not possible to build something stable and scalable with Julia yet.
I know both languages are very similar in performance to general purpose use cases, but would Go be a better option (considering maturity, available packages, etc.) at this moment?
I really like both of them, but I’d like to stick with Julia because of its power related to data science, one of the areas I work on.
If accessing other backend systems, like databases or message buses, is critical, then you’ll have much better supported packages with Go. Go won’t do “data science” nearly as well as Julia, so if that’s the bulk of your code and you can get by with the Julia packages for any other system access, then you’ll be better off with Julia.
Note that you probably want to strip out the Auth elements to get it running (it references local storage) and this DockerFile (change to your .jl files) may just work for Linux (I had to play with the CPU target to get it working in Kubernetes)
FROM julia:1.6.1
# in Project.toml and add that to the container instead.
# Only add Project.toml, Manifest.toml, docker-simple.jl, and /src
ADD *.toml ./usr/bin/CHANGE_TO_YOUR_PROJ_DIR/
EXPOSE 8080
ADD . ./usr/bin/CHANGE_TO_YOUR_PROJ_DIR/
WORKDIR /usr/bin/CHANGE_TO_YOUR_PROJ_DIR/
ENV JULIA_PROJECT=@
ENV JULIA_CPU_TARGET=generic,cx16;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)
ENV JULIA_NUM_THREADS=16
ENV JULIA_DEPOT_PATH="/root/.julia/"
RUN julia --project=@. -E 'using Pkg;pkg"activate ."; pkg"instantiate";pkg"precompile";'
CMD julia --project=@. -e 'include("src/CHANGE_TO_YOUR_ENTRY_FILE.jl"); CHANGE_TO_YOUR_ENTRY_FILE.run();'
on the comment re GO vs Julia (I can’t actually spot your original GO reference?) - if you have a microservice architecture then you would/could/should use both. If you need DB connections. ODBC.jl is the pkg to use, e.g. this post.