after install have a xqerl greeter
grantmacken opened this issue · comments
- add supervisor and server code for loading xquery main modules in priv dir
- add main module 'greeter.xq` to priv/modules dir
- add associated css and image files to priv/static/assets dir
- alter cowboy routes so
http://localhost:8081/xqerlwill display greeter page - write check in actions to show greeter is working
Yep I know I could have chucked a index.html file into /priv/static/assets and let the cowboy static assets handler do its thing.
however I want to use the priv/modules dir for other stuff so I did it this way.
xqerl always listens on port 8081.
so after installing xqerl there could be a greeter on http://localhost:8081
to show the install has been completed successfuly.
Prior practice: Greeters on port 80 after installing nginx or openresty.
example:
Welcome to OpenResty!!
If you see this page, the OpenResty web platform is successfully installed and working.
Further configuration is required.
For 0nline documentation and support please refer to openresty.org.
Thank you for flying OpenResty.
This is a really good idea.
I think a default greeter should be overridable by a user XQuery module. Then it's there, unless it shouldn't be. right?
I think a default greeter should be overridable by a user XQuery module. Then it's there, unless it shouldn't be. right?
I am not sure how cowboy would handle route duplication conflict, if a restXQ generated route conflicts with another redefined route. I'll do some research and test.
However because we are listening on port 8081, the most likely scenario for a xqerl web app is in the context of being behind a reverse proxy which handles TLS termination and creates a reverse proxy route to xqerl on port 8081.
Unless you are a large corporation, the web developer will have a bundle registered domains, tied to a single SNI cert so they can use single VPS or cloud host provider. The reverse proxy not only terminates TLS, but also can rewrite routes based on the domain. In my case my proxy route will end up something like https://example.com => http://xq/example.com/home/index
where xq is the running host container with published port mapping 80 => 8081
So my web facing restXQ paths will always be domain prefixed eg /{domain}/{collection}/{item}
Not only is the web facing restXQ route based on a domain, the same domain is used for db XDM item access.
To cut a long story short, my restXQ paths never route on '/'.
Pr #52 merged