<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>I'm using JWT (JSON Webtoken) in my app to manage API-first stuff
(pure REST accessed with JQuery).
<a class="moz-txt-link-freetext" href="https://github.com/ambs/Dancer2-Plugin-JWT">https://github.com/ambs/Dancer2-Plugin-JWT</a><br>
But I'm also using session cookies (Dancer2::Session::Cookie) on
the Web side of the app.</p>
<p>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.</p>
<p>Good luck!</p>
<p>--<br>
Mikko Koivunalho<br>
</p>
<div class="moz-cite-prefix">On 04/04/2022 17:23, Ruth Holloway
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d089326c-3eef-44d5-a5c7-5ec5e6fa9ab5@www.fastmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
<div>Hi Andy,<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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:<br>
</div>
<div><br>
</div>
<div> send_as JSON =>
MyApp::GoFetchTheStuff(body_parameters->get('param'));<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Authentication—I'd probably stick with session cookies, and
D2PAE. There are probably leaner-and-meaner ways, but it's a
familiar, functional tool.<br>
</div>
<div><br>
</div>
<div>I'll take a moment here and put in a plug for a couple of
modules I've released, <a
href="https://metacpan.org/dist/DBIx-Class-Schema-ResultSetNames"
moz-do-not-send="true" class="moz-txt-link-freetext">https://metacpan.org/dist/DBIx-Class-Schema-ResultSetNames</a> and <a
href="https://metacpan.org/dist/Dancer2-Plugin-DBIx-Class"
moz-do-not-send="true" class="moz-txt-link-freetext">https://metacpan.org/dist/Dancer2-Plugin-DBIx-Class</a>.
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'});<br>
</div>
<div>(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.<br>
</div>
<div><br>
</div>
<div>Just my two cents (USD). That, and 498 more, and you might be
able to buy a cup of $beverage_of_choice.<br>
</div>
<div><br>
</div>
<div>Ruth Holloway<br>
</div>
<div><br>
</div>
<div>On Mon, Apr 4, 2022, at 10:00, Andy Beverley wrote:<br>
</div>
<blockquote type="cite" id="qt" style="">
<div>Dear all,<br>
</div>
<div><br>
</div>
<div>I'm interested in your opinions on how you would
architecture a new web <br>
</div>
<div>application, if you were to start one today.<br>
</div>
<div><br>
</div>
<div>I'll be starting a new application soon and this is a
chance to take a <br>
</div>
<div>fresh look at things. Normally I would go with a simple <br>
</div>
<div>Dancer/Template::Toolkit setup.<br>
</div>
<div><br>
</div>
<div>However, I'm thinking that I should make this an "API
first" application <br>
</div>
<div>(i.e. using static HTML pages and rendering all the content
using a <br>
</div>
<div>Jaavscript framework making API calls)<br>
</div>
<div><br>
</div>
<div>That then begs the question as to what the best back-end
architecture <br>
</div>
<div>is, if only using it to render JSON.<br>
</div>
<div><br>
</div>
<div>Also, if only serving API requests with the back-end, how
would you <br>
</div>
<div>manage authentication? Would you still use cookies or would
you use some <br>
</div>
<div>sort of tokens?<br>
</div>
<div><br>
</div>
<div>Any thoughts welcome!<br>
</div>
<div><br>
</div>
<div>Thanks,<br>
</div>
<div><br>
</div>
<div>Andy<br>
</div>
<div><br>
</div>
<div>_______________________________________________<br>
</div>
<div>dancer-users mailing list<br>
</div>
<div><a href="mailto:dancer-users@lists.preshweb.co.uk"
moz-do-not-send="true" class="moz-txt-link-freetext">dancer-users@lists.preshweb.co.uk</a><br>
</div>
<div><a
href="https://lists.preshweb.co.uk/mailman/listinfo/dancer-users"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.preshweb.co.uk/mailman/listinfo/dancer-users</a><br>
</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dancer-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dancer-users@lists.preshweb.co.uk">dancer-users@lists.preshweb.co.uk</a>
<a class="moz-txt-link-freetext" href="https://lists.preshweb.co.uk/mailman/listinfo/dancer-users">https://lists.preshweb.co.uk/mailman/listinfo/dancer-users</a>
</pre>
</blockquote>
</body>
</html>