5 ms·

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

sdfhdhjdw3 4y ago
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?
- moelf 4y ago
  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
  - krastanov 4y ago
    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.
    - moelf 4y ago
      IIRC both Oxygen and Genie use HTTP.jl
- ChrisRackauckas 4y ago
  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.
- soledades 4y ago
  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.
blindseer 4y ago
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.
lbhdc 4y ago
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.
- lf-non 4y ago
  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.
  - lbhdc 4y ago
    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?
    - lf-non 4y ago
      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.
drannex 4y ago
This looks eerily similar to how Plugs (cowboy) work in Elixir, which is a great method.

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?

moelf 4y ago
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
- krastanov 4y ago
  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.
  - moelf 4y ago
    IIRC both Oxygen and Genie use HTTP.jl
ChrisRackauckas 4y ago
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.
soledades 4y ago
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.

blindseer 4y ago

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.

lbhdc 4y ago

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.

lf-non 4y ago
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.
- lbhdc 4y ago
  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?
  - lf-non 4y ago
    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.

drannex 4y ago

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