What is the expected way to import services?

I’m creating a new service using yarn rw g service users, then trying to import something from that service into a function under api/src/functions/. The dev server is then giving me an error saying Error: Cannot find module '../services/users'.

If I import using import { createUser } from 'src/services/users' I get the error. If I instead use import { createUser } from 'src/services/users/users' the error goes away.

Shouldn’t the Redwood import helpers be cleaning up these imports? Or am I not supposed to import services from functions?

Thanks!

Hi @bennett That is definitely strange import behavior most likely having to do with how Functions work. I first want to make sure you’re intentionally attempting to create a specific, separate Lamdba Function. Locally this Function will be available at localhost:8911/functionName and deployed on Netlify at https://your-site.com/.netlify/functions/functionName. (These paths are handled for you automatically by Redwood.)

Am I understanding correctly that this is what you’re trying to do?

If so, @rob has created a Cookbook Doc that will be coming out next week to help with this. In the meantime, try using require(...) instead of import {...} as this might have to do with Functions not having ES module support. So even if you do get src/services/users/users to work locally, it might break when deployed. So try:

const createUser = require('../services/users/users').createUser

Yep - I’m trying to use Google APIs server-side, which means I’m handling the OAuth flow in separate Lamba functions (one to generate the auth url, and one to handle the callback). I adapted the approach from projects like this one from Netlify. If there’s a better way to do the OAuth dance in Redwood I’m very interested!

I’m still working on it so I haven’t deployed it to Netlify yet. I’ll try it as-is (importing from src/services/users/users), and if that breaks on Netlify I’ll try your suggestion of using require.

Thank you for the suggestion!

This pattern src/services/users/users makes me think that this should support directory named plugin - but that only works in webpack, and not on the api side, so we’ll need to add support via babel.

@bennett
What I might suggest for now, is to try the following:

// src/lib/services
import importAll from '@redwoodjs/api/importAll.macro'
import {
  makeServices,
} from '@redwoodjs/api'

const services = importAll('api', 'services')
export default makeServices({ services })

And then use it like this: import services from 'src/lib/services'

You’ll now be able to access services.user

Thanks for the recommendation. I’ve started handling the OAuth flow on the client side for the time being, so actually removed the immediate need to import services from other functions, but I’m sure I’ll need it again soon and will try this approach.

2 Likes

We do have a Redwood Auth package making its debut within a week. It will support Netlify Auth and Auth0 at this time. More options to come including extending and rolling your own Auth (but no timelines or schedule for these as of now).

Not sure if this will be helpful or not based on your needs.

This pattern src/services/users/users makes me think that this should support directory named plugin - but that only works in webpack, and not on the api side, so we’ll need to add support via babel.

@peterp Nudge here to open up a new GH Issue if applicable. :wink:

Yep - currently working integrating with the Redwood auth provider after installing the 0.6.1 canary. :slight_smile: There’s another thread where I’m discussing with @peterp the best way to get this to work with the Google OAuth2 flow.

1 Like