Lib vs services (Redwood file structure)

Given all the interest in services, I’ve been trying to dig in.

That quickly made me realize there’s this thing called lib, which I knew was there, but didn’t really think about all that much. lib, according to the tutorial:

…contains one file, db.js, which instantiates the Prisma database client. You are free to send additional options, if necessary. You can use this directory for other code related to the API side that doesn’t fit in functions or services.

Auth also shows up here.

But why aren’t these things just services? Not saying they should be, but what’s the cutoff? What code goes in here vs services? Things that don’t need to be tested or nested in dirs? Things that are provided by Redwood? Obviously nothing in lib will ever be mistaken for a resolver. But services seem to be about a lot more than just resolvers.

So I think if we’re going to clarify services, we need to clarify lib too.

Yeah, understood about the confusion. But Lib really isn’t much of a thing (yet). The reason for db.js is due to future plans to add a Redwood wrapper-type-implementation to the Prisma Client so we can do things like handle workarounds for Prisma Relations. This hasn’t been implemented yet, but there were also increasing questions about “what exactly is this db thing in my Services?” – it wasn’t clear it was the Prisma Client because it was hidden in the API package.

The common theme between the existing db and auth .js files are that they are consumed by Services but are not specifically “application/business logic” themselves. E.g. they’re not queries or mutations.

1 Like