[HN Gopher] Oxygen.jl: A breath of fresh air for programming web...
___________________________________________________________________
Oxygen.jl: A breath of fresh air for programming web apps in Julia
Author : logankilpatrick
Score : 86 points
Date : 2022-06-06 12:48 UTC (10 hours ago)
(HTM) web link (forem.julialang.org)
(TXT) w3m dump (forem.julialang.org)
| lbhdc wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sdfhdhjdw3 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| IIRC both Oxygen and Genie use HTTP.jl
| ChrisRackauckas wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-06-06 23:01 UTC)