[ANN] Oxygen.jl: A breath of fresh air for programming web apps in Julia

Package Announcements
, , ,
1

I’m excited to announce Oxygen.jl, a micro-framework built on top of the HTTP.jl library that’s designed to simplify building web applications in Julia. Full disclosure, the design of the API itself takes heavy inspiration from the FastApi python library

using Oxygen
using HTTP

@get "/greet" function(req::HTTP.Request)
    return "hello world!"
end

# both path parameters are automatically converted to Float64's 
@get "/multiply/{a}/{b}" function(req, a::Float64, b::Float64)
    return a * b
end

# all objects are automatically deserialized into JSON
@get "/getdata" function()
    return Dict("message" => "hello!")
end

# mount all nested files inside the "content" folder under "/static"
@staticfiles "content" "static"

# start the web server
serve()

Features

  • Straightforward routing (@get, @post, @put, @patch, @delete and @route macros)
  • Out-of-the-box JSON serialization & deserialization
  • Optional type definition support for Path parameters
  • Helper functions to parse & transform the body of requests & responses
  • Hosting static files
  • Built-in multithreading support

In the future, it may not always depend on HTTP.jl. I have some ambitious ideas which may include replacing HTTP.jl with something akin to Starlette in julia. But for the time being, I’m focusing more on practical and developer-focused features to add to the framework

Coming soon: I’m currently working on adding automatic doc generation (openapi 3.0 format)

Why build another web framework?

That’s a great question, why create another package if Julia already has full stack frameworks like Genie.jl that can do just about anything?

My quick answer: most people don’t need all features that come with these heavyweight packages. About a month ago, I was one of those people looking to quickly spin up a web server to prototype some ideas.

I wanted something lightweight and straightforward, and I didn’t want to spend a lot of time learning a new syntax. Ideally, I wanted something similar to Flask or FastApi but in Julia.

So, I set out to create this package and design a no-nonsense api that would hopefully feel familiar to JS and Python programmers and drive greater adoption in these communities.

Feature Requests

If you have any ideas or feature requests, please feel free to open an issue on the github page or startup a thread in the discussion section!

53 Likes
2

Very cool stuff! Excited to see more web tools in the ecosystem. I like all the convenience router functionality here.

As an FYI, I’m just about done with an HTTP.jl 1.0 release that includes several overhauls of different parts of the codebase. The aim is for things to be much more stable, more documented/stable APIs, and hopefully can remain a trusted and foundational package for the ecosystem. I’d love to hear thoughts/feedback on how we can make it better and serve its purpose.

31 Likes
3

Hey Quinn,

First off, thanks for all the work you’ve put into the HTTP & JSON3 packages. I spent the past week looking through those repos and got a sense of the insane amount of effort that has been poured into them.

After reading through all that, It just reaffirmed that I have neither the drive nor the time to attempt replacing it. My time would be much better spent adding more productivity-enhancing features to my package.

Personally, I’d love to see multithreading support added to HTTP.jl. I was able to get around this by adapting some code I found from a discussion on the julia discourse forums. But I’m sure there’s a much better and more efficient way to do this at the HTTP.jl layer. Not to mention, adding this change there would help the other web-related projects across the ecosystem.

4

For sure. Would you mind opening an issue on the HTTP.jl repo with what the goals would be of incorporating multithreading? I’ve seen some examples that handle this in the “handler” layer, but I’m interested to hear if something more tightly integrated with the core HTTP code would also be helpful. Or perhaps just including a “standard handler” implementation for like a ThreadedHandler would be helpful for people.

5

How did I only hear/read about this now, this is amazing!

The way I so far had been doing extremely rudimentary multithreading is shown here but I’m sure that what’s in Oxygen is a much better way of doing it since this still has only 1 thread distributing the requests in the first place.

Time to rewrite RemoteHPC to use oxygen though :smiley:

4 Likes