3 ms·

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 defini

by 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.
ndortega 4y ago
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

by lbhdc 4y ago

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.

ndortega 4y ago

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