[Bug?]: Calling serverless function does not work when server started with yarn rw serve

[standuprey]

What's not working?

I have a serverless function called from graphql to do some async work.
This works fine when the server is started with yarn rw dev or in production.
But when I start the server with yarn rw serve I get connect ECONNREFUSED ::1:8911

How do we reproduce the bug?

Here is a repo to reproduce the bug:

GitHub

If you start this with yarn rw dev there is a button on the homepage that works, but it doesn’t work if you start the app with rw build && rw serve

Ticket created from this discussion: https://community.redwoodjs.com/t/error-calling-a-function-from-graphql-when-started-with-rw-serve/5476

What's your environment? (If it applies)

System:
    OS: macOS 14.0
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.0 - /private/var/folders/g7/0v2mwcd50dv822c6142lth1h0000gp/T/xfs-054dda13/node
    Yarn: 3.6.0 - /private/var/folders/g7/0v2mwcd50dv822c6142lth1h0000gp/T/xfs-054dda13/yarn
  Databases:
    SQLite: 3.39.5 - /usr/bin/sqlite3
  Browsers:
    Chrome: 118.0.5993.117
    Safari: 17.0
  npmPackages:
    @redwoodjs/cli-storybook: 6.3.2 => 6.3.2
    @redwoodjs/core: 6.3.2 => 6.3.2

Are you interested in working on this?

• I'm interested in working on this

[jtoar]

Thanks for reporting and including a reproduction @standuprey! Funny I brought up edge cases like this just earlier this week. There's some differences between dev and serve:

• dev
  • runs two child processes, one for web and one for api
  • web and api are at different ports (by default, 8910 and 8911 respectively)
  • on http://localhost:8911, api functions are at /, but can also be accessed via the web side at http://locahost:8910/.redwood/functions (since we proxy them to http://localhost:8911/)
• serve
  • runs one process; web and api are served together as it were
  • they're both served at 8910, or the web's port by default
  • all api functions are at http://localhost:8910/.redwood/functions. requests there aren't proxied—that's actually where the api functions are. nothing is served at http://localhost:8911/

I was going to make serve act the same as dev—just start two processes. But stepping back a bit, it looks like you want to call one of your api functions (here "myfunc") from graphql right? Or was there more to it than that?

[standuprey]

yes, that’s it basically, calling a function from another function.

i had try to make executeAsync point to localhost:8910/.redwood/functions instead of localhost:8911 but I get the same error. see https://github.com/standuprey/redwood-async-func-call/pull/1/files

[dac09]

Hey @standuprey - I recently had to deal with a similar problem on ssr-streaming. I haven't reviewed your usecase though, so no thoughts on why you are trying to hit a function endpoint.

When you run on rw serve - the server doesn't listen on anything other than 127.0.0.1, so if you put in localhost you'll receive the error you're reporting. You could have a env var for this, and have a utility function that would just replace localhost for you:

function swapLocalhostFor127(hostString: string) {
  return hostString.replace('localhost', '127.0.0.1')
}

I hope this is helpful, and not actually making things worse 🤣, that's what I currently have in the experimental ssr setup!

[dthyresson]

I have a serverless function called from graphql to do some async work.

I still don't 100% understand why a function is called by the a graphql service resolver.

If the feature needs to be shared, the logic can be put in something shared like a lib.

The graphql resolver/service is async, so, I can't see which the async part need to be a function.

Is it that you want to "execute and forget" meaning trigger the async part but return right away?

If so, I think the new defer directive in realtime is what you may want.

See: #9235

and https://the-guild.dev/graphql/yoga-server/v4/features/defer-stream#using-defer

If these needs to be deployed on serverless like Vercel or Netlify, let me know -- I think defer should be possible.

[dac09]

Hey @standuprey! Just in triage mode at the moment - there's a few suggestions on this thread that are worth trying!

For now I'll close it the issue, but if you feel like you need more of a solution from the framework side feel free to comment and re-open.