ASGI equivalent in Julia for High performance?

mks · October 15, 2021, 8:08am

Hello,

I wonder if there will be more work on an ASGI Framework equivalent in Julia. I see all the recent Python webframeworks use ASGI, like FastAPI, Scarlette or Quart. How come we do not see this in Julia?

FastCGI appears to be the underlying tech of ASGI Frameworks in Python.

There is FastCGI.jl, but it doesn’t get so much attention it seems. Afaik HTTP.jl is not made this way, but it may be on the roadmap?

Jeff_Emanuel · October 15, 2021, 2:52pm

Aren’t all those trying to work around the Python GIL problem?

mks · October 15, 2021, 3:34pm

ASGI is the asynchronous version of WSGI (Flask) which is well explained here: HOWTO Use Python in the web — Python 2.7.18 documentation

I cannot explain it so elaborated, hence I’d like to cyte Clark E. Evans from another discussion here:

So we have:

Multi-Threading · The Julia Language
By default, Julia starts up with a single thread of execution. This can be verified by using the command Threads.nthreads() :

julia> Threads.nthreads()
1

Lets start Julia with 4 threads:

$ julia --threads 4

https://docs.julialang.org/en/v1/base/parallel/#Tasks

By default, Tasks are coroutines.

github.com

tanmaykm/FastCGI.jl/blob/master/src/bufferedoutput.jl#L11


      
          const MAX_WRITE_SIZE = Int(typemax(UInt16))
          struct BufferedOutput
              action::Function
              waiter::Task
              iob::IOBuffer
              lck::ReentrantLock
          
              function BufferedOutput(action::Function; delay::Float64=0.05, bytelimit::Int=1024*8, maxbuff::Int=MAX_WRITE_SIZE)
                  lck = ReentrantLock()
                  iob = IOBuffer(;maxsize=maxbuff)
                  waiter = @async begin
                      while isopen(iob)
                          timedwait(delay) do
                              lock(lck) do
                                  position(iob) >= bytelimit
                              end
                          end
                          lock(lck) do
                              if position(iob) > 0
                                  action(take!(iob))
                              end

If you have a long-running request, you really should @yield occasionally if you want your server to be responsive. It seems that the lower-level FastCGI code is yeilding the active task while waiting for sockets.
The TLDR; so long as you’re not writing any long-running responses, you can probably just ignore this all and it’ll work just fine. Lower-level libraries will yield as needed. A corollary is that when ever you interact with the database, read/write to a file, or write data to a socket, another task might be scheduled to run. You have to be careful thinking about the libraries you use that do IO.
The benefit of using HTTP’s Request is that it builds a complete response string before sending it to the socket, avoiding an unexpected interruption in processing.

So, in the Python world, there is ASGI Documentation — ASGI 3.0 documentation which could be used by all sorts of backend implementations. The Julia community has not contemplated an “API” for web programming, but it might benefit them to emulate something like ASGI. This is based upon a “coroutine” based assumption rather than preemptive multi-tasking.

Jeff_Emanuel · October 15, 2021, 7:24pm

Thanks. I do all my web work in Go, but I’m interested in starting to do some in Julia, and it’s good to where there may be limitations.

lawless-m · November 16, 2021, 1:44pm

FastCGI is not related to Python and has absolutely nothing to do with the GIL.

FastCGI is just a way for long lived processes to remain live between Web requests such that Web requests don’t pay the startup penalty over and over.

Which makes it a suitable partner for Julia.

It also made it a good partner for Python which also suffers from startup costs.

And Java.

It also means you don’t need to build an entire web serving mechanism, battle hardened on the live internet instead of rolling one yourself and then forgetting about CSRF and huge headers, and 10Mb data urls etc. being thrown at you.