Hacker News new | past | comments | ask | show | jobs | submit login

I think Flask is like Ruby Sinatra and Perl Dancer.

I've used Dancer quite a bit. Some for larger apps (30+ pages)

This is how I typically lay out a Dancer app. Starting with a top level directory of application name, say "MyApp", I put the routes in different directories instead of jumble them all up in one file. As an example, lets use an app that handles and tracks customers and orders. So something like this:

  └── Routes
    ├── API
    │   ├── Component
    │   │   ├── Customer.pm
    │   │   └── Order.pm
    │   ├── Customer.pm
    │   └── Order.pm
    ├── API.pm
    ├── Customer.pm
    └── Order.pm
(templates should have a similar layout in a separate 'Views' directory)

Routes/Customer.pm would handle basic requests like GET /Customer/list and POST or GET Customer/1

While routes handling json/ajax only requests (from jquery ect) would be in Routes/API/Customer.pm. Routes/API.pm would be an api for stuff that doesn't directly involve a Customer or Order object (perhaps returning json from an inventory table or something)

And if you get tired of requesting json just to convert it into html with javascript and you want the power of a template (without a SPA); I fetch that stuff with jquery .load() using the 'Component' routes (dynamic parts of a webpage). For example, perhaps when making a new quote, you select a specific customer and you want open orders to be displayed in a popup or inline div somewhere. Using jquery .load(), you would just easily fetch /API/Component/Customer/Open-Orders/<cust id#>, ect and then just inline the returned html. If you stick to a rule of "components can only return html and not cause a page refresh", you will keep from getting too big of mess with them.

This is just sorta a method I made from various best practices from other frameworks. Perhaps its barftastic, but I haven't been complaining about it.

This is reminding me strangely of the original, non-single-entry-point style of writing PHP.

I'm actually kind of surprised that we haven't seen a return to that style, with more modern sensibilities: each route directly mapping to a file containing the route's procedure body + any view templates for that route; a single "common" file at the project root containing dependency-imports and model declarations, etc.

In the end, it wouldn't actually work like old PHP—you'd still actually have a single entry-point and all the code would be preloaded rather than loaded into an ephemeral request context—but you'd be able to code as if the opposite was true.

Reminds me a bit of the "oldschool sensibilities" of coding with something like Löve2D, actually.

Erf, mapping URLs to filesystem path is cute but you lose control.

I like Jinja2 templating and haven't fully jumped on the client side generation train. But I'm partially on that train and do do some client side generation. Particularly for elements that need to appear and disappear with the data lurking in the background. What I found is that I can pass json directly to the script portions of a Jinja template and avoid a second request (although certainly subsequent requests are often necessary). It might not be the "right way" but it works for a lot of things and is pretty simple.

I do similar with Mojolicious, but have less of a defined difference between API/JSON routes and HTML routes, having grown the webapp organically for four years or so now. Unfortunately it started as a Mojolicious::Lite app, and the singe routes+logic controller file ballooned to 4k lines (sans templates and copious DBIC modules with custom methods) before I started forcing time to refactor them into separate modules like you've outlined above. I'm about 30% done but the usability (development wise) and maintainability increase is phenomenal.

To be clear, Mojolicious advises a layout like above from the beginning for any serious app (and even provides a utility to automatically convert Mojolicious::Lite apps, for the most part), but when it's in production already and Mojolicious lite makes it a little too easy to put that off when it's so easy to just add another route... Well, I have only myself to blame. :/

I'm really interested in well designed route structures,especially for sites that include both HTML and JSON variants of their data. It's API design any way you look at it, which is always a hard problem, but I haven't come up with general rules that I'm quite happy with yet. Guides or example sites are welcome.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact