Search code examples
javascriptaws-lambdagatsbynetlifytoml

Gatsby + Netlify-Dev Lambda Functions - Lambda Server Port always different?


I am trying to use netlify-dev and their serverless functions with my gatsby project.

Here is my netlify.toml file

[build]
  functions = "lambda"
  command = "gatsby build"
[dev]
  command = "gatsby develop"
  functionsPort = 34567
  port = 8000
  publish = "public"
  targetPort = 8000

I added this to my Gatsby Config

const proxy = require("http-proxy-middleware")
module.exports = {
  developMiddleware: app => {
    app.use(
      "/.netlify/functions/",
      proxy({
        target: "http://localhost:34567",
        pathRewrite: {
          "/.netlify/functions/": "",
        },
      })
    )
  },
  //...

However, there seems to be something wrong with the port I always get a new random port, everytime I run netlify dev

Netlify Dev ◈
◈ Injected build setting env var:  CLOUDINARY_CLOUD_NAME
◈ Injected build setting env var:  CLOUDINARY_API_KEY
◈ Injected build setting env var:  CLOUDINARY_SECRET
◈ Starting Netlify Dev with gatsby
Waiting for localhost:8000.
◈ Lambda server is listening on 61271 //*** I would expect this to be 34567? ***
success open and validate gatsby-configs - 0.066s
⠋ load plugins

What am I missing here? And why is the port always different?


Solution

  • Despite you are setting port 8000, it won't be able to use it because it's already being used by gatsby develop. That's why it always gives you a different port number. If you want the port number to be always the same, use another random number (8888 is used by default if you don't set a port).

    About your netlify functions, unless you want to set a different port for any particular reason, I would leave them as they are and simply call them by using: /.netlify/functions/your-function-name.

    I mostly use this minimum configuration on my netlify.toml

    [build]
    functions = "functions"
    

    Then, in your code, you don't need to worry about port numbers.

    UPDATE This seems to be a problem with latest netlify-cli release. There is an issue already open. Rolling back to a previous version seems to be a good temporary solution.