Hi, I'm using JWT (JSON Webtoken) in my app to manage API-first stuff (pure REST accessed with JQuery). https://github.com/ambs/Dancer2-Plugin-JWT But I'm also using session cookies (Dancer2::Session::Cookie) on the Web side of the app. PostgreSQL is my choice, too. Although I went the route of designing my own DB access framework on top of SQL::Abstract::Pg (SQL::Abstract). The framework supports the app's business logic and is an attempt to do things lighter than DBIx::Class. But don't take this route (your own framework) without a good reason. Good luck! -- Mikko Koivunalho On 04/04/2022 17:23, Ruth Holloway wrote:
Hi Andy,
At $WORK we do a lot of this kind of thing; some of our older apps are... less beautiful... than newer ones. I've been gradually improving things as I have need to touch the code.
If I was doing it today (and I am, on a personal project), I'd be doing it as a single-page sort of app, where you have a few templates, and use JS on the front-end to make API calls. At $WORK, we use Foundation, jQuery and DevExtreme UI widgets, and on my personal project, jQuery, and WebUI widgetry and layout. There are fancier tools; $WORK experimented with Vue for a bit, but while complexity is not always your enemy, It Is Never, Ever Your Friend.
For the backend, a nice performant DB—PostgreSQL is my hammer-of-choice, with DBIx::Class. In your API routes, you can do things like:
send_as JSON => MyApp::GoFetchTheStuff(body_parameters->get('param'));
Nothing wrong at all with using Dancer/Dancer2 as an API-first app. with the REST and AJAX plugins—it may be slight overkill, but I wouldn't hesitate to go that direction.
Authentication—I'd probably stick with session cookies, and D2PAE. There are probably leaner-and-meaner ways, but it's a familiar, functional tool.
I'll take a moment here and put in a plug for a couple of modules I've released, https://metacpan.org/dist/DBIx-Class-Schema-ResultSetNames and https://metacpan.org/dist/Dancer2-Plugin-DBIx-Class. The former adds resultset naming tricks to the Schema object, and the D2 plugin is a forklift upgrade for D2::Plugin::DBIC, that adds the ResultSetNames as D2 DSL words, with optional prefixes. So instead of rset('Whatevah')->search({ foo => 'bar' }), you can just use dh_whatevahs({ foo => 'bar'}); (I'd be interested in seeing your D2PAE Provider class see my plugin as well as the older DBIC plugin... or I can shamelessly plagiarize your plugin to make a new Provider.) The plugins provide a way to make your DB searches and find a little more semantically friendly.
Just my two cents (USD). That, and 498 more, and you might be able to buy a cup of $beverage_of_choice.
Ruth Holloway
On Mon, Apr 4, 2022, at 10:00, Andy Beverley wrote:
Dear all,
I'm interested in your opinions on how you would architecture a new web application, if you were to start one today.
I'll be starting a new application soon and this is a chance to take a fresh look at things. Normally I would go with a simple Dancer/Template::Toolkit setup.
However, I'm thinking that I should make this an "API first" application (i.e. using static HTML pages and rendering all the content using a Jaavscript framework making API calls)
That then begs the question as to what the best back-end architecture is, if only using it to render JSON.
Also, if only serving API requests with the back-end, how would you manage authentication? Would you still use cookies or would you use some sort of tokens?
Any thoughts welcome!
Thanks,
Andy
_______________________________________________ dancer-users mailing list dancer-users@lists.preshweb.co.uk https://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@lists.preshweb.co.uk https://lists.preshweb.co.uk/mailman/listinfo/dancer-users