Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev server + backend server at once #82

Closed
layik opened this issue May 12, 2020 · 15 comments
Closed

dev server + backend server at once #82

layik opened this issue May 12, 2020 · 15 comments

Comments

@layik
Copy link
Member

layik commented May 12, 2020

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
Copy link
Member Author

layik commented May 12, 2020

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
Copy link
Member Author

layik commented May 12, 2020

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

layik added a commit that referenced this issue May 12, 2020
@layik
Copy link
Member Author

layik commented May 12, 2020

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

@layik
Copy link
Member Author

layik commented May 17, 2020

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
Copy link
Member Author

layik commented May 17, 2020

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
Copy link
Member

mpadge commented May 17, 2020

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
Copy link
Member Author

layik commented May 17, 2020

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
Copy link
Member Author

layik commented May 17, 2020

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 added a commit that referenced this issue May 17, 2020
@layik
Copy link
Member Author

layik commented May 18, 2020

Nor does it happen on Travis, again strange!

@mpadge
Copy link
Member

mpadge commented May 18, 2020

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
Copy link
Member

mpadge commented May 20, 2020

@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
Copy link
Member Author

layik commented May 20, 2020

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
Copy link
Member

mpadge commented May 21, 2020

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
Copy link
Member Author

layik commented May 22, 2020

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
Copy link
Member Author

layik commented Oct 13, 2020

Reopen if this is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants