Make server more flexible #576
Conversation
|
Thanks, good ideas! The only problem I see is that if somebody pip-installs Gramps Web API and uses the CLI to run it with the new
<h1>Welcome to Gramps Web API!</h1>
<p>If you see this page, Gramps Web API is up and running.</p>
<p>Gramps Web API provides a REST API to work with a Gramps family tree database.
It also servers as the backend of Gramps Web, an integrated web app.
To run Gramps Web, <a href="https://github.com/gramps-project/gramps-web/releases">download
the frontend</a> and set the Gramps Web API `STATIC_PATH` configuration variable.</p>What do you think? |
| max_workers = min(32, os.cpu_count() + 4) | ||
|
|
||
| def open_webbrowser(): | ||
| time.sleep(1.0) |
There was a problem hiding this comment.
That gives the server time to start. If you open the page too quickly, you'll get an error.
| app.logger.addHandler(file_handler) | ||
| app.logger.setLevel(debug_level) | ||
|
|
||
| print("Running gramps-web...") |
There was a problem hiding this comment.
Yes, I debated that. On one hand, the gramps-web-api is just the REST server. Thinking of suggesting renaming gramps-web to gramps-web-frontend, plus gramps-web-api together as gramps-web (and I'm thinking about a package just called gramps-web). What do you think?
There was a problem hiding this comment.
Thinking of suggesting renaming gramps-web to gramps-web-frontend, plus gramps-web-api together as gramps-web
That's exactly the naming we have. The frontend used to have a separate name (Gramps.js, "the Gramps Web frontend"), but we renamend the repository to gramps-web because it lead to confusion.
From the point of view of the combined web application, it would make sense to have a monorepo and combined packaging, but so far we still have them separated. Since the API can be used for other things as well, I think it kind of makes sense. And for proper web-based deployments, it's anyway more complicated (celery, nginx, etc.).
What we could do is to add a convenience command to download a frontend.
| import urllib.parse | ||
|
|
||
|
|
||
| class TransLogger(object): |
There was a problem hiding this comment.
(object) is not needed (I know this is copy-pasted from somewhere else, but we can modernize a bit)
There was a problem hiding this comment.
I can fix a couple of other things there too. Now that I know you are open to this PR, I will do that.
|
|
||
| def open_webbrowser(): | ||
| time.sleep(1.0) | ||
| new = {"tab": 0, "window": 1}[open] |
There was a problem hiding this comment.
This will raise a KeyError if the user provides any unexpected string. I think it would be better to use a click choice option for the browser flag.
|
One thing I'm unsure about: which things will break when using threads. So far, Web API was either served by the flask development server (which is single-threaded) or by gunicorn using worker processes (not threads). Did you investigate that already? |
I assume that we will not run those two paths with the other flags. I'm developing a third flow that runs the server + has frontend preinstalled and runs locally. |
|
First, thanks for being open to changes! Regarding the:
I think that is good in general. Currently, one doesn't know if the frontend is available or not, right? It would be good to show something like: |
|
Does it ever make sense to run the gramps-web-api server without a frontend? I guess for testing. Anything else? Maybe that is just an error, without something like |
In principle, it could serve as backend of various different apps. Somebody could develop some tailored frontends, say with some dedicated forms for entering census data; or for native mobile apps. That was the original idea when we started the API without a frontend. It can also be used as a way to do batch operations on a Gramps tree without using Python code, just HTTP request. |
This PR does the following:
--use-wsgito add a wsgi wrapper--hostfor wsgi listener--debug-levelset the log level--log-fileif you want to log to file--openopen the browser on host:port--max-workersfor wsgi server