ATFutures / geoplumber

Serve geographic data from R and consume with scalable front end.
https://atfutures.github.io/geoplumber/
59 stars 7 forks source link

dev server + backend server at once #82

Closed layik closed 3 years ago

layik commented 4 years ago

At the moment, there is no strategy to start both separately without one blocking the other.

Plumber uses ... (will fill that gap later) to start the backend server. And npm start does the front end, which is a blocking command.

At least on macOS cannot be sent to the back with say system("npm start &) or system("npm start", wait = FALSE). Though works fine if continues to block which makes impossible for backend to run.

S needs better system and systeme2 understanding or more from R. Relevant functions are: gp_plum and gp_plumb_front. Of course, in the shell, always done it in two different windows (tmux or not).

layik commented 4 years ago

Current thoughts are:

Premise: Windows does not kill child processes when their parents die. Based on this:

  1. Use nohup or similar FOR Unix and use nothing on Windows to run background processes for npm start.
  2. Always keep plumber blocking to the last command.

That way, if front is needed either in the background with backend or on its own. And the backend takes priority as it also is the better/production env as it serves what the front dev server serves.

layik commented 4 years ago

Experimental solution to this is what gp_map uses. Bypass the whole webpack/transpiling issues discussed in #81

layik commented 4 years ago

R package future was not useful or not used correctly see #58 and others.

layik commented 4 years ago

Thanks @mpadge this is useful, I must have not used callr::r_bg in the past properly. If list params is not passed the plumber process exits I think.

Thanks again.

layik commented 4 years ago

Gives me great pleasure to share first ever reprex of geoplumber:

library(geoplumber)

d <- file.path(tempdir(), "gp")
gp_create(d)
#> Creating directory: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> To build/run app, set working directory to: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> Standard output from create-react-app works.
#> You can run gp_ functions from directory: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> To build the front end run: gp_build()
#> To run the geoplumber app: gp_plumb()
#> Happy coding.
setwd(d)
ps <- gp_plumb()
#> WARNING:
#> Looks like geoplumber was not built, serveing API only.
#> To serve the front end run gp_build() first.
ps
#> PROCESS 'R', running, pid 1419.
Sys.sleep(1) # just in case
ps
#> PROCESS 'R', running, pid 1419.
require(RCurl)
#> Loading required package: RCurl
webpage <- getURL("http://localhost:8000")
webpage <- readLines(tc <- textConnection(webpage)); close(tc)
tail(webpage)
#> [1] "    <p>build missing</p>" "  </div>"                
#> [3] "</div>"                   ""                        
#> [5] "</body>"                  "</html>"
ps$kill()
#> [1] TRUE

Created on 2020-05-17 by the reprex package (v0.3.0)

mpadge commented 4 years ago

Amazing timing - I'm grappling with exactly those issues in another repo right now, trying to get callr::r_bg() to properly serve a plumber instance. I'll check out what you've done asap. Great to see you back @layik

layik commented 4 years ago

Hi Mark, got the insight from that repo, report package or something, I thought I had put a link in the above comment.

Yes, must get geoplumber out!

layik commented 4 years ago

I don't know why but devtools::test() test call to callr::r_bg() generates too many "Unable to find env file..." error which is hitting this bit. When doing R CMD Check that does not happen. Strange!

layik commented 4 years ago

Nor does it happen on Travis, again strange!

mpadge commented 4 years ago

Yeah, the env stuff is exactly what i need to spin up tomorrow to get my stuff working. I need to stick variables in the local (non-R) environment, and then read them in via the background process. That's one of my tomorrow morning tasks, so I'll have a look at your code at the same time, and ping when i've got a solution.

mpadge commented 4 years ago

@layik I managed to fix my errors, mostly by using the debugging abilities of callr via stuff like this:

ps <- callr::r_bg (f, list (r = r,
                            port = as.integer (port)),
                            stdout = "/tmp/out",
                            stderr = "/tmp/err") 

Notes:

  1. The as.integer(port) is really important, because trying to $run(port = port) a plumber object will fail if port is not an integer
  2. The important bits: stdout and stderr dump all logging info to those /tmp files which can then be inspected to work out what's going wrong.
layik commented 4 years ago

Thank you very much Mark, I take it you didn't (thankfully) hit the 'No environment file in temp dir' error.

I will note these as they are too precious and who knows might save me days.

mpadge commented 4 years ago

No, but stuff i'll be doing today will involve passing envvars through, but r_bg has it's own env list that is passes anyway (callr::rcmd_safe_env()), so you can easily just add whatever you want to that, and pass it as the env par instead of the default.

layik commented 4 years ago

Missed this comment, thanks Mark.

I think I need to get to know the package better so again your insights will come handy. callr has solved a huge hurdle for the package, though not had a chance to work on it this week.

layik commented 3 years ago

Reopen if this is needed.