wtsi-hgi/hgi-web

HGI Web Application

The full service stack for the management of HGI systems:

• API token provider
• Core service APIs
• API (backend) server
• Client (frontend) server

License

Copyright (c) 2014, 2015 Genome Research Limited

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Note that the use of a range of years within any copyright statement contained within this distribution should be interpreted as being equivalent to a list of years, including the first and last year specified and all consecutive years between them.

hgi-web's Issues

Preserve paths when behind reverse proxy

If the isomorphic frontend is reverse-proxied anywhere other than at the root, the paths will not resolve correctly.

For example, when looking for Bootstrap CSS, the path is /bootstrap/css/bootstrap.css. If the app is served from, say, /app then the above path will fail as the actual file will be served from /app/bootstrap/css/bootstrap.css.

n.b., We can't change the paths in the templates to fix this, as we're using the URL statefully. For example, if we're at the app root, then bootstrap/css/bootstrap.css will work, but if we're at the /about app route, then we'd need ../bootstrap/css/bootstrap.css, etc. That's why we used the absolute path in the first place.

Thus, this needs to be resolved at the reverse proxy layer. mod_proxy_html can rewrite URLs using ProxyHTMLURLMap (see SO and the Apache documentation). This seems the best solution to try...

Move navbar links into API

Navbar links should not be hardcoded into the frontend. Instead, it would be better if they were served by the API. The upshots of this would be:

• Consolidating all the duplicated navbar links into a single GET; this would generalise the somewhat cumbersome routing that currently exists in the client
• Potential for customising navbar links on a per-user basis
• Decouples the frontend for proper orthogonality

Note that navbar links are effectively client-specific. As such, I would suggest having a two-tier API route structure: the public API that everyone knows and loves; and client endpoints that would not usually be consumed directly by the user. Unless anyone has any better ideas, I'm inclined to distinguish the latter by prefixing first level endpoints with an underscore (e.g., /_bookmarks).

I don't anticipate there being many of these, and only one client for the foreseeable future, so would rather put them at the root level than, say, /_client/:id/:function. The latter, of course, would provide much greater flexibility, but if that time comes, it would be a trivial change to our frontend.

Sort out shibboleth configuration for balancing between web1 and web2

Prefix on URL links in 'brunch'

Brunch currently assumes it's running in a web root of '/'.

Related work?

Hello,

I noticed this project, and it appears your group may already be creating an implementation of something that's just an idea in a discussion I'm part of: Mec-iS/mild-QL#3.

Just wanted to check how the idea relates to your work and whether we might work together. It would be great to hear any of your thoughts from your experience in this area!

The basic idea is to support GraphQL and/or Falcor requests using a proxy layer over either a SPARQL endpoint or a HYDRA/REST API server.

1. Request flow for HYDRA/REST backend:

GraphQL/Falcor client ->
GraphQL/Falcor server/middleware as proxy layer ->
one or more HYDRA server endpoint(s) as backend layer ->
Relational datastore

or

2. Request flow for SPARQL endpoint backend:

GraphQL/Falcor client ->
GraphQL/Falcor server/middleware as proxy layer ->
SPARQL endpoint as backend layer ->
Triplestore