Gatsby: Proxying lambda requests with gatsby serve

[zslabs]

Description

developMiddleware is lost in CLI serve command for Netlify Lambda functions.

Steps to reproduce

Using netlify-lambda and the following rewrite for local access within gatsby-config.js, requests are getting through just fine when developing (from the tutorial):

  developMiddleware: (app) => {
    app.use(
      '/.netlify/functions/',
      proxy({
        target: 'http://localhost:9000',
        pathRewrite: {
          '/.netlify/functions/': '',
        },
      }),
    );
  },

However, when I want to use gatsby serve, even when attempting to run things like so, the path rewrites are not happening (but are still available on port 9000):

"gatsby build && concurrently \"yarn start:lambda\" \"gatsby serve -p 10000\""

Overriding port here to not conflict with lambda server. Any thoughts on how we can expose the rewrite for the CLI serve command? Thanks!

Expected result

Proxy API requests just as gatsby develop does.

Actual result

The :9000 endpoint is still available, but not respecting proxy. I do understand the serve is not meant to run as develop, but with the current config; it makes local build testing not work correctly.

Environment

  System:
    OS: macOS 10.14.4
    CPU: x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Shell: 3.0.0 - /usr/local/bin/fish
  Binaries:
    Node: 10.15.3 - /usr/local/bin/node
    Yarn: 1.12.1 - ~/.yarn/bin/yarn
    npm: 6.5.0 - ~/.npm-packages/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 73.0.3683.86
    Firefox: 65.0.1
    Safari: 12.1
  npmPackages:
    gatsby: 2.2.11 => 2.2.11
    gatsby-image: 2.0.34 => 2.0.34
    gatsby-plugin-canonical-urls: 2.0.12 => 2.0.12
    gatsby-plugin-catch-links: 2.0.13 => 2.0.13
    gatsby-plugin-feed: 2.1.0 => 2.1.0
    gatsby-plugin-google-tagmanager: 2.0.11 => 2.0.11
    gatsby-plugin-manifest: 2.0.24 => 2.0.24
    gatsby-plugin-netlify: 2.0.13 => 2.0.13
    gatsby-plugin-netlify-cms: 3.0.16 => 3.0.16
    gatsby-plugin-node-fields: 2.0.1 => 2.0.1
    gatsby-plugin-react-helmet: 3.0.11 => 3.0.11
    gatsby-plugin-sass: 2.0.11 => 2.0.11
    gatsby-plugin-sharp: 2.0.30 => 2.0.30
    gatsby-plugin-sitemap: 2.0.10 => 2.0.10
    gatsby-plugin-twitter: 2.0.13 => 2.0.13
    gatsby-remark-autolink-headers: 2.0.16 => 2.0.16
    gatsby-remark-copy-linked-files: 2.0.11 => 2.0.11
    gatsby-remark-custom-blocks: 2.0.7 => 2.0.7
    gatsby-remark-embed-video: 1.7.1 => 1.7.1
    gatsby-remark-images: 3.0.10 => 3.0.10
    gatsby-remark-prismjs: 3.2.6 => 3.2.6
    gatsby-remark-relative-images: 0.2.2 => 0.2.2
    gatsby-remark-relative-links: 0.0.3 => 0.0.3
    gatsby-remark-responsive-iframe: 2.1.1 => 2.1.1
    gatsby-source-filesystem: 2.0.28 => 2.0.28
    gatsby-transformer-remark: 2.3.8 => 2.3.8
    gatsby-transformer-sharp: 2.1.17 => 2.1.17
    gatsby-transformer-yaml: 2.1.10 => 2.1.10
  npmGlobalPackages:
    gatsby-cli: 2.4.6

[zslabs]

Was thinking that I might be able to use serve.json if https://github.com/zeit/serve was being used, but having trouble locating what the serve command is actually running; plus serve-handler doesn't support absolute URLs for the different port 😢

[zslabs]

I was able to get things working by not using gatsby serve at all and implementing light-server with the following config in a light-server.json file:

{
  "port": 8000,
  "proxy": "http://localhost:9000",
  "proxypaths": ["/.netlify/functions"]
}

With the following modifications to my package.json file:

"build-serve": "yarn build && concurrently \"yarn start:lambda\" \"light-server -s public/ --config light-server.json\"",

But would love to know if there's a built-in way that I can handle this without the additional dep.

[wardpeet]

I don't think it's a bad idea to create a new API extension like developMiddleware for serveMiddleware

[zslabs]

@wardpeet That'd be pretty nice for sure! Less deps FTW 🎉

[wardpeet]

I'll write down a short description on how to fix it.

1) In packages/gatsby/src/commands/serve.js you'll need to add this part of code

// Expose access to app for advanced use cases
const { serveMiddleware } = config

if (serveMiddleware) {
  serveMiddleware(app)
}

2) Add serveMiddleware to our config validation: packages/gatsby/src/joi-schemas/joi.js.

3) Last but not least update our docs.

[iFlameing]

@wardpeet can you assign me this issue?

[lannonbr]

We'd love for your contribution @iFlameing 🎉

[sidharthachatterjee]

Just closed the pull request that @iFlameing opened after a discussion with the team. We'd like to keep serve as lean as possible since it isn't meant to be used other than during testing and adding another API for this doesn't seem like a worthy investment!

We could perhaps unify express middleware APIs in v3 (and rename from developMiddleware) but in the mean time, you should be able to copy serve and use the code in the PR locally @zslabs

Opened an issue for that in https://github.com/gatsbyjs/gatsby/issues/13631 and closing this in the mean time

[zslabs]

@sidharthachatterjee Cool, no worries! Here's a blog post that goes into a bit more detail how I accomplished the workaround for anyone who needs this for the future.

[bradvogel]

Hey all - it's been more than a year and we have a strong need to be able to hook into Gatsby's production express router. Would you be willing to take a PR to add a serveMiddleware parameter (per the suggestion in this comment)?