Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxying lambda requests with gatsby serve #12924

Closed
zslabs opened this issue Mar 28, 2019 · 10 comments
Closed

Proxying lambda requests with gatsby serve #12924

zslabs opened this issue Mar 28, 2019 · 10 comments
Assignees
Labels
good first issue Issue that doesn't require previous experience with Gatsby help wanted Issue with a clear description that the community can help with.

Comments

@zslabs
Copy link
Contributor

zslabs commented Mar 28, 2019

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
Copy link
Contributor Author

zslabs commented Mar 28, 2019

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
Copy link
Contributor Author

zslabs commented Mar 29, 2019

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
Copy link
Contributor

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

@zslabs
Copy link
Contributor Author

zslabs commented Apr 15, 2019

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

@wardpeet wardpeet added help wanted Issue with a clear description that the community can help with. type: feature or enhancement labels Apr 16, 2019
@wardpeet
Copy link
Contributor

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)
}
  1. Add serveMiddleware to our config validation: packages/gatsby/src/joi-schemas/joi.js.

  2. Last but not least update our docs.

@DSchau DSchau added the good first issue Issue that doesn't require previous experience with Gatsby label Apr 16, 2019
@iFlameing
Copy link
Contributor

@wardpeet can you assign me this issue?

@lannonbr
Copy link
Contributor

We'd love for your contribution @iFlameing 🎉

@sidharthachatterjee
Copy link
Contributor

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 #13631 and closing this in the mean time

@zslabs
Copy link
Contributor Author

zslabs commented Apr 25, 2019

@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
Copy link

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Issue that doesn't require previous experience with Gatsby help wanted Issue with a clear description that the community can help with.
Projects
None yet
Development

No branches or pull requests

7 participants