in reply to Re^2: Perl, Android web app, AJAX, JSON
in thread Perl, Android web app, AJAX, JSON

What others said about the value of previous advice is accurate.

such as cookie based client authentication, logging, caching, memory and performance optimizations etc

Apache cannot do some of that (memory and performance) for your code and might or might not be doing other parts as expected or to best practices. This thread is a bit vague though so it's hard to give real advice or discuss individual issues.

For my part, I am almost always going to agree with anything Corion or LanX recommend. Yes to REST, never-ever to SOAP, yes to Ajax/HTML5 + whatever functionality (for persistent authentication or location services for example) the mobile device exposes through it that you need; use device agnostic JavaScript libraries. Keep up to date with security, OWASP is your best one stop shopping. nginx + uWSGI + plack harnessed apps should be preferred over apache and modperl. Always use standard packages like JSON::XS. Never roll your own. It seems easier or faster than frameworks, like Mojolicious, at first but except in the most trivial cases where you already know what you're doing, it's false economy. Take the learning hit up front instead of floundering your way to it down the road or landing in maintenance Hell.

  • Comment on Re^3: Perl, Android web app, AJAX, JSON

Replies are listed 'Best First'.
Re^4: Perl, Android web app, AJAX, JSON
by monx663 (Sexton) on Nov 21, 2017 at 20:32 UTC
    Great post, Your Mother. Thanks.

    Actually, it was me that mentioned your quoted keywords in response to a user suggesting I should modify my CMS to use RPC::Any::Server in order for it to act as a hub for the various mobile app clients.
    I especially liked reading about what PSGI/Plack is.
    Seeing this CMS is 100% object oriented, with most packages relying on package inheritance, making it Plack "harnessable" should not be too difficult. (famous last words)
    This web CMS essentially only has a single point of entry with every web request going to its main handler, which in turn invokes the relevant CMS Perl Package to handle the GET or POST, then return its HTML as a string ref to the main handler.


    Thanks for the homework
    Cheers,
    Konstantinos