Postgraphile: Feature request: add support for mounting PostGraphile's GraphiQL under an express route e.g. `/subdir/graphql`

Created on 7 May 2018 · 16Comments · Source: graphile/postgraphile

I'm submitting a ...

[ ] bug report
[x] feature request
[ ] question

PostGraphile version: 4.0.0b7

Steps to reproduce

_Environment variables:_

"NODE_ENV": "production",
"PORT": "3000",
"PGHOST": "localhost",
"PGPORT": "5432",
"PGUSER": "postgres",
"PGPASSWORD": "secret",
"PGDATABASE": "my_db"

_Server code (TypeScript)_

import * as express from "express";
import { postgraphile } from "postgraphile";

const app = express();
const router = express.Router();
router.use(postgraphile(undefined, { graphiql: true }));

app.use("/subdir", router); // ** important ** express listens for anything in the "subdir" subdirectory
app.listen(process.env.PORT || 3000);

Current behavior:

When requesting localhost:3000/subdir/graphiql, the page is unable to load its assets due to relative URLs lacking a leading period (.).

_Current page source:_

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>GraphiQL</title>
    <meta name="robots" content="noindex" />
    <link href="/_postgraphile/graphiql/static/css/main.63526d56.css" rel="stylesheet">
</head>
<body>
    <div id="root"></div>
    <script>window.POSTGRAPHILE_CONFIG={graphqlUrl:'/graphql',streamUrl:null}</script>
    <script type="text/javascript" src="/_postgraphile/graphiql/static/js/main.878a1713.js"></script>
</body>
</html>

Expected behavior:

Asset URLs have a leading period (.).

_Expected page source:_

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>GraphiQL</title>
    <meta name="robots" content="noindex" />
    <link href="./_postgraphile/graphiql/static/css/main.63526d56.css" rel="stylesheet">
    <!--        ^ dot added here -->
</head>
<body>
    <div id="root"></div>
    <script>window.POSTGRAPHILE_CONFIG = { graphqlUrl: './graphql', streamUrl: null }</script>
    <!--                                                ^ dot added here -->
    <script type="text/javascript" src="./_postgraphile/graphiql/static/js/main.878a1713.js"></script>
    <!--                                ^ dot added here -->
</body>
</html>

✋ release blocker 💅 enhancement

Source

devuxer

👍5

Most helpful comment

Either a well-tested PR fixing this (checking it works with all our supported servers, for all modes, and including hot reloading) or someone sponsoring the work would be welcome. It’s not a _priority_ for me as PostGraphile is intended to be used as a root-level middleware and supports moving to a custom path via graphqlRoute. It’s definitely something I want to fix in v5 though.

benjie on 3 Jul 2018

👍3

All 16 comments

We don't currently support mounting at a non-root URL and it's not a priority for me to add that facility; however I'd be happy to look at a tested PR that adds that functionality - the _postgraphile thing has been a pain for a number of users. TBH I'd rather put everything under /graphql directly like express-graphql does - that way you only need to give PostGraphile one argument. Sadly we cannot do that in v4 (short of a feature flag) as it would be a breaking change.

benjie on 7 May 2018

@benjie,

I did submit a PR (see above), but perhaps you are saying it's not a viable solution?

Also, I'm trying to run the tests (on Windows), but most of them are failing due to:

error: password authentication failed for user "Dan"

I tried setting the TEST_PG_URL in .travis.yaml but that doesn't seem to be read by the testing apparatus.

devuxer on 7 May 2018

The commit above is not sufficient on it's own, there are other things in _postgraphile other than the GraphiQL assets (e.g. the GraphiQL event stream). With that said; I've made a spec so we should be able to update our GraphiQL to adhere to the spec and thus not require specific configuration for this to work; see: https://github.com/skevy/graphiql-app/pull/120

benjie on 7 May 2018

👍2

i ran into this today. the docs offer a graphiqlRoute option, which to me, implied i could do such a thing.

i did similar tracing and landed on the same results. can we review what stands in our way from enabling this?

update the middleware to always be on some /sub/path for all _postgraphile assets
reconcile all consumers of _postgraphile to use requested subpath

perhaps an api change is warranted, where we don't allow graphqlRoute + graphiqlRoute. instead--maybe just graphqlRoute, which can be nested, and graphiqlRoute follows the nesting? just thinking out loud.

cdaringe on 3 Jul 2018

context: i previously had multiple koa apps mounted to my node server. e.g. one to /public, which is a static fileserver, and one to /api. in the presence of this issue, i now just mount /api instead to /, and prefix all routes w/ /api.

cdaringe on 3 Jul 2018

benjie on 3 Jul 2018

👍3

Removing pr-wanted because I have some in-progress code towards achieving this goal (don't want duplication of effort).

benjie on 15 Sep 2018

🎉1

Support added in #894 and #899 and released as postgraphile@next - please test and let me know how you get on. Note you need to set the graphqlRoute to the FULL path; e.g.

app.use('/path/to', postgraphile(db, schema, {graphqlRoute: '/path/to/graphql', graphiqlRoute: '/path/to/graphiql', absoluteRoutes: true}));

benjie on 2 Nov 2018

Apologies for commenting on a closed issue, but absoluteRoutes does not quite completely fix the issue for me. I'm mounting Postgraphile on an express.js route on a server that's accessed through a sub-path on a reverse proxy. In total, that means that the path the client uses is /api/route/graphql, the "originalUrl" on the API server is /route/graphql, and within the route it's just /graphql. Sure, that's a bit complex, but it's what I've got.

I think the fundamental issue here is that a single parameter graphqlRoute is being used for two different purposes: To define what the local route is, as well as the public route. Maybe it'd be easier to then configure them separately, much like Webpack uses output.path and output.publicPath?

This approach would allow for graphqlRoute and graphiqlRoute to keep their current meanings, and for absoluteRoutes to be replaced by something like publicRootPath, a string value that by default would be an empty string but e.g. in my case could be set to /api/route.

eemeli on 15 Nov 2018

Solid idea, much cleaner. I'm going to see if I can get this done before we release 4.1 so we don't have to support the absoluteRoutes option. (I'll make it throw, rather than silently disappear.)

benjie on 15 Nov 2018

👍1

Proposal: add setting externalUrlBase; we should remove absoluteUrls.

defaults to ''
should not have a trailing slash
is prepended onto any asset URLs
e.g. {graphiqlRoute: '/graphql', externalUrlBase: '/subdir'} would expect that GraphQL is accessible via external URL /subdir/graphql (and this is where GraphiQL should send queries)
e.g. {graphqlRoute: '/graphql', externalUrlBase: 'http://example.com/subdir'} would expect that GraphQL is accessible via external URL http://example.com/subdir/graphql

Other than asserting there is no trailing slash, and ensuring it's a valid URL, little in the way of validation can be done for this.

We should try, if we can, to detect that we're mounted on a subpath automatically. If we cannot do so, we should warn if we notice that url and originalUrl differ and externalUrlBase is not set.

We should see how this works with Lambda.

benjie on 19 Nov 2018

On fix, update: https://stackoverflow.com/a/52556025/141284

benjie on 19 Nov 2018

All of this has been implemented in https://github.com/graphile/postgraphile/pull/919

benjie on 22 Nov 2018

🎉1

@eemeli This is now out in postgraphile@next; could you tell me if externalUrlBase does the trick please? https://github.com/graphile/postgraphile/releases/tag/v4.1.0-rc.2

benjie on 23 Nov 2018

Yes, rc.2 and externalUrlBase works for me. :)

eemeli on 24 Nov 2018

AWESOME 🎉 Thanks for getting back to me @eemeli