Oxygen.jl: A breath of fresh air for programming web apps in Julia | Hacker News Reader

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

forem.julialang.org

I'm glad to see this, and I'm hoping to use it. Genie bundled waay too much and was too slow for development. If this cuts down on REPL load times / Revise times, it'll be win in my book.

I still think there's a LOOONGGG way to go for Julia web frameworks, and specifically here there's auth / cookie handling / supporting static assets etc and a number of features I'd like to see enabled as plugins or add ons (not unlike flask). But for now, it seems like a great start.

I feel like this may be a unpopular opinion, but I would be interested in hearing what other people think.

I am not a fan of web frameworks that require defining the path of a handler where the handler is defined. I feel like this is something that is nice if you have a very small project, but makes it difficult to understand the api surface as a project gets larger and things start being abstracted. Even though you have to parse out your own url params, I would likely choose HTTP.jl over another abstraction.

I inherited an old java project where all routes were defined in web.xml. One of the biggest productivity drains was to keep having to look back and forth between the route configuration and the servlet implementation. Over time the route mapping xml had grown to a humongous size. Coming from ruby this kind of indirection was very hard me for quite some time.

When we switched to spring annotation driven configuration it was a breath of fresh air. The mapping of http verbs, params etc. were all colocated with the services and there was no need to keep jumping across files.

Very few people may use sinatra now, but its spirit will live on among countless frameworks that have embraced its minimalism to whatever extent their host platform allow.

That is a very fair reason for structuring it that way. I agree that there is, to some extent, more overhead for the developer who normally works on and maintains the code base. However, I feel like it is easier as a reader to understand what a service does and how to integrate with it having all of the paths in a centralized location.

How do you normally think about making that information discoverable in your webapps?

Now a days I mostly always use either graphql/openapi depending on the history of the project and the preferences of the team. So there typically is a spec for the API.

I usually prefer a code-first approach and the open source tooling is able to extract the spec for me from annotations - which becomes a centralized location for exploration or generating clients.

Hi there, I just wanted to chime in and let you know that you don't have to define the request handler in the same place as the path. You can import handlers from other modules and just pass them to one of the routing macros. The reason why you see that pattern so often in the docs is that I wanted to keep the examples as simple as possible

Oxygen.jl supports several different design styles and leaves the choice up to the developer.

- Central file with routes & import request handlers from other modules

- Define routes & handlers across multiple modules and just call serve() from the main module

Below is a quick example of how you could separate your application logic from any routing logic

------- B.jl -------

  module B 

  export greet 

  function greet()
      "hello world!"
  end

  end

------- main.jl -------

  module Main 
  using Oxygen 
  include("B.jl"); using .B

  @get "/hello" greet

  serve()

  end

Uh-oh, I hope Julia doesn't go the way of dozens of libraries re-implementing everything, like python. I would much rather prefer it stayed the course of 1 high-quality implementation for each thing.

> most people don't need all features that come with these heavyweight packages

Why not contribute to Genie.jl an interface that is simpler then?

well, Julia is not class-based OOP so it's kind of Unix like where packages does one thing right and you just compose them or someone makes a meta package that compose them

There are caveats to that statement. Semi-formal human social decisions need to be made in order for an ecosystem to agree on a set of interfaces. Some of them are part of Julia Base, which makes it easy, but some of them emerged through a lot of community work, especially in SciML (autodiff interfaces, advanced array interfaces, statistics interfaces, file and serialization IO,). This has not happened yet in the webdev side of things (Pluto, Genie, etc do not share as much) so it is difficult to compose things well there.

Edit: I removed HTTP.jl from the list as it is a lower-level library with a different set of constraints to interoperability.

IIRC both Oxygen and Genie use HTTP.jl

It's built on HTTP.jl, so it reuses all of that code and is just a higher level interface to a basic HTTP server. Genie.jl and complete web frameworks are a completely different beast with different use cases and I agree they should be kept separate.

Idk, it’s stretching things a bit to say web servers are “one thing.”

Agree with you in general, but in this particular case, I am glad there is an alternative to Genie.jl.

This looks eerily similar to how Plugs (cowboy) work in Elixir, which is a great method.

Reply on news.ycombinator.com