Hi, I'm making a bot. I'm trying to integrate it into a Dancer2 app, in order to make a REST API for it, and later be able to interact with it from the browser. It logs in to an external webservice, like this: $bot->login($username, $password); This stores some credentilals in the bot, which uses them for other requests. And then it does some other stuff: $->do_stuff; The bot exists and can make these very basic operations from a script. To create the REST API with Dancer2, I made something in those lines: my $bot = MyBot->new; post '/login.json' => sub { my ($username, $password) = (params->{username}, params->{password}); $bot->login($username, $password); # Store credentials in the bot }; This works perfectly. And then post '/do_stuff.json' => sub { $bot->do_stuff; } This doesn't work: when I call '/login.json', followed by '/do_stuff.json', the second request fails because the credentials are not present: it seems to not be interacting with the same $bot object than the login request. It works if add $bot->login( ... ) at the beginning of the '/do_stuff.json' subroutine, but I don't want to login at each new request. What is a clean solution for this use case? * 30 minutes later * I have found Dancer2::Plugin::Adapter<https://metacpan.org/pod/Dancer2::Plugin::Adapter>and the "singleton" scope, which seems to be what I need. But it won't install. I will send a RT ticket. Any idea for an alternative solution?
Every request from the web server generates a call to the application code reference that is built by "dance". Variables do not persist between requests, nor should they. You could solve it by keeping the variable in a cache. You could use Memcached, KiokuDB, or the likes. Another way would be to simply login every time you make a request. This is what's done in scopes in KiokuDB. Another way to solve it, uglier IMHO, is using singletons. But that's just having global scope for stuff, which you should generally avoid. On Thu, Dec 5, 2013 at 6:24 PM, Pierre M <piemas25@gmail.com> wrote:
Hi, I'm making a bot. I'm trying to integrate it into a Dancer2 app, in order to make a REST API for it, and later be able to interact with it from the browser.
It logs in to an external webservice, like this: $bot->login($username, $password); This stores some credentilals in the bot, which uses them for other requests. And then it does some other stuff: $->do_stuff; The bot exists and can make these very basic operations from a script.
To create the REST API with Dancer2, I made something in those lines: my $bot = MyBot->new; post '/login.json' => sub { my ($username, $password) = (params->{username}, params->{password});
$bot->login($username, $password); # Store credentials in the bot }; This works perfectly.
And then post '/do_stuff.json' => sub { $bot->do_stuff; } This doesn't work: when I call '/login.json', followed by '/do_stuff.json', the second request fails because the credentials are not present: it seems to not be interacting with the same $bot object than the login request.
It works if add $bot->login( ... ) at the beginning of the '/do_stuff.json' subroutine, but I don't want to login at each new request.
What is a clean solution for this use case?
* 30 minutes later * I have found Dancer2::Plugin::Adapter<https://metacpan.org/pod/Dancer2::Plugin::Adapter>and the "singleton" scope, which seems to be what I need. But it won't install. I will send a RT ticket. Any idea for an alternative solution?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Great stuff Sawyer, thank you! I had a look at Dancer2::Session::Memcached, and just realized that I only really need to store a session token (from a 3rd party service that the bot interacts with). So I probably only have to use Dancer2::Session::Cookie. Let's see how to integrate that elegantly into the design... If I even need to store a whole object in the future, I'll know where to look. --- Pierre Masci I check email a couple times daily; to reach me sooner, you can send me a text message via this page: https://awayfind.com/mascip On 6 December 2013 11:53, sawyer x <xsawyerx@gmail.com> wrote:
Every request from the web server generates a call to the application code reference that is built by "dance". Variables do not persist between requests, nor should they.
You could solve it by keeping the variable in a cache. You could use Memcached, KiokuDB, or the likes. Another way would be to simply login every time you make a request. This is what's done in scopes in KiokuDB.
Another way to solve it, uglier IMHO, is using singletons. But that's just having global scope for stuff, which you should generally avoid.
On Thu, Dec 5, 2013 at 6:24 PM, Pierre M <piemas25@gmail.com> wrote:
Hi, I'm making a bot. I'm trying to integrate it into a Dancer2 app, in order to make a REST API for it, and later be able to interact with it from the browser.
It logs in to an external webservice, like this: $bot->login($username, $password); This stores some credentilals in the bot, which uses them for other requests. And then it does some other stuff: $->do_stuff; The bot exists and can make these very basic operations from a script.
To create the REST API with Dancer2, I made something in those lines: my $bot = MyBot->new; post '/login.json' => sub { my ($username, $password) = (params->{username}, params->{password});
$bot->login($username, $password); # Store credentials in the bot }; This works perfectly.
And then post '/do_stuff.json' => sub { $bot->do_stuff; } This doesn't work: when I call '/login.json', followed by '/do_stuff.json', the second request fails because the credentials are not present: it seems to not be interacting with the same $bot object than the login request.
It works if add $bot->login( ... ) at the beginning of the '/do_stuff.json' subroutine, but I don't want to login at each new request.
What is a clean solution for this use case?
* 30 minutes later * I have found Dancer2::Plugin::Adapter<https://metacpan.org/pod/Dancer2::Plugin::Adapter>and the "singleton" scope, which seems to be what I need. But it won't install. I will send a RT ticket. Any idea for an alternative solution?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
I'm not loving the idea of storing a 3rd party session token, it's a bit of a pain to pass it around and it's not really scalable. Caching the bot itself between each REST request works, but I came accross a possibly nicer idea: My bot could be running in a Gearman worker, and I would give orders with a Geaman client. Possibly with Dancer::Plugin::GearmanXS, if I used Dancer instead of Dancer2. It looks the tool for the job. I'll try it in two weeks, when I'm back from holidays.
It's the same thing, IMHO. It's a state. Keeping it in Memcached, token in a cookie, external service, etc. Whichever one you find comfortable is the best. :) On Fri, Dec 6, 2013 at 9:29 PM, Pierre M <piemas25@gmail.com> wrote:
I'm not loving the idea of storing a 3rd party session token, it's a bit of a pain to pass it around and it's not really scalable. Caching the bot itself between each REST request works, but I came accross a possibly nicer idea:
My bot could be running in a Gearman worker, and I would give orders with a Geaman client. Possibly with Dancer::Plugin::GearmanXS, if I used Dancer instead of Dancer2.
It looks the tool for the job. I'll try it in two weeks, when I'm back from holidays.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Wow !! The code in my first email worked, the bot IS shared between all REST calls. I just needed to run plackup bin/app.pl instead of plackup -L Shotgun bin/app.pl It's the Shotgun option that made my app.pl be re-initialized each time. No need for a memcache, no need for workers, it just works! Dancer is my app online, with a state =) --- Pierre Masci I check email a couple times daily; to reach me sooner, you can send me a text message via this page: https://awayfind.com/mascip On 7 December 2013 11:13, sawyer x <xsawyerx@gmail.com> wrote:
It's the same thing, IMHO. It's a state. Keeping it in Memcached, token in a cookie, external service, etc. Whichever one you find comfortable is the best. :)
On Fri, Dec 6, 2013 at 9:29 PM, Pierre M <piemas25@gmail.com> wrote:
I'm not loving the idea of storing a 3rd party session token, it's a bit of a pain to pass it around and it's not really scalable. Caching the bot itself between each REST request works, but I came accross a possibly nicer idea:
My bot could be running in a Gearman worker, and I would give orders with a Geaman client. Possibly with Dancer::Plugin::GearmanXS, if I used Dancer instead of Dancer2.
It looks the tool for the job. I'll try it in two weeks, when I'm back from holidays.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (2)
-
Pierre M -
sawyer x