get local_examples/test_repeater_beakr.R to work

[jonathancallahan]

At the outset, our goal was to create a replacement for the deprecated jug package.

Some of the joy of using jug was that you didn't have to know much about unix or web servers and could just write some R code.

I have created two scripts to demonstrate what was possible with jug and what I would like to be possible with beakr:

• local_executables/test_repeater_beakr.R
• local_executables/test_repeater_jug.R

Looking at the diff shows how easy I was hoping it would be to convert our old web services:

$ diff test_repeater_jug.R test_repeater_beakr.R
8c8
< library(jug)
---
> library(beakr)
11c11
< jug() %>%
---
> newBeakr() %>%
15c15
<   get("/", function(req, res, err) {
---
>   GET("/", function(req, res, err) {
36c36
<   get("/repeater", function(req, res, err) {
---
>   GET("/repeater", function(req, res, err) {
88c88
<   simple_error_handler_json() %>%
---
>   errorHandler() %>%
92,93c92
<   serve_it()
---
>   startBeakr(daemon = FALSE)

The ** jug** version works as expected with a simple ability to walk through the debugger and quit with a single click on the stop button. It also generates desired output in a variety of formats and an informative, json formatted error message if times > 10.

The beakr version doesn't currently work and I don't understand why. It also has a strange behavior where I have to click the stop button 3 times to get it to end.

We should talk at some point so that I can understand what has changed in the overall design and why. Perhaps there is a better way to rewrite the code I am familiar with. But it has to be a great improvement to justify any refactoring it will force on us. We have several complex, operational web services that currently depend on the deprecated jug package and my primarily goal is to support those going forward with a non-deprecated package.

I see a couple of good options at this point:

• Educate me about how beakr works -- perhaps the functionality I want is already there but I just need different syntax.
• Add features to beakr so that it can work in the way I expect.
• If beakr has some super-cool functionality but is incompatible with what I want, perhaps we should release beakr and create a second MazamaWebUtils package that has the maintainable rump of the jug package I'm looking for.

[hmrtn]

This does work. Beakr does require considering some slight semantic differences for accessing the methods of the req, res, err. Most method names should be the same, except they are camel-case, rather than underscored, and typically not abbreviated. Here are some examples of difference in the test_repeater's.

# Beakr Version: 
text <- setIfNull(req$parameters$text, "Howdy")

# Jug version: 
text <- setIfNull(req$params$text, "Howdy")

# Beakr Version:
res$contentType(mime::mimemap[responseType])

# Jug Version:
res$content_type(mime::mimemap[responseType])

I have pushed the fixed version.
I am certainly not opposed for name changes and using underscores if you prefer - as long as we are consistent package-wide.

Keep in mind, all available methods to the user can be seen in the documentation. For example: help('Response').

As for the Stop button thing - sourcing or running R code while another process is running will queue the processes. Its really easy to forget the running beakr and hit the source button when one is running, only to open another beakr on the previous one's stop.