Figure out how to better support configuring the libraries Wasp uses

[sodic]

Users can't configure Prisma client and Lucia without monkey patching. Examples:

• https://discord.com/channels/686873244791210014/1322852155929133056/1323275245913903217
• https://discord.com/channels/686873244791210014/1322181954275250256/1322181954275250256

Without this option, using Wasp takes away many of the underlying technologies' capabilities.
We should figure out a consistent way to expose these configurations.

What we currently support:

• The configureQueryClient hook we expose for configuring React Query.

[infomiho]

Related #2116

[Case-E]

We are building a mobile app using Wasp auth and this feature of setting the session lengths in main.wasp or elsewhere would be helpful. If we could also do this based on the device being used, that will be golden.

Wondering if you could allow a function (returning int)/int to evaluate the value for the session length config. For example, I would write a custom function that will return the length based on the device.

[sodic]

Thanks for the info @Case-E. I believe this is another thing we intend to tackle before 1.0.

Let me just see if I got this part right...

Wondering if you could allow a function (returning int)/int to evaluate the value for the session length config. For example, I would write a custom function that will return the length based on the device.

I'm gussing you'd be executing this function on the server, as server is the one who decides on the session's properties. How would you then get the necessary client detail to this function, through the request? What's your ideal workflow?

You can share hypothetical code if you'd like?

[Case-E]

Thanks @sodic! You’re right — I ended up mixing up two different thoughts here.

For the email sender, I was originally considering a function-based approach (e.g., use a dummy sender locally and the configured sender in prod). But thinking about it more, that was mainly because I felt limited as an end user. A simple boolean property like useDummyForLocal would actually be enough, and I could take a stab at that separately in another PR.

On the session length side: The default of 30 days of inactivity actually works for us. My earlier function suggestion wasn’t well thought out. What I had in mind was letting the client adjust fetch the session length dynamically (for example, based on User-Agent or a custom header like X-Platform: mobile-app). For our use case though, we don’t actually need any changes unless the default of 30 days is reduced.

I also started some exploratory work around setting the session length — here’s the PR. It’s still rough, untested, and may not be something I move forward with since we don’t need it immediately.

Edit: Adding a screenshot showing our hacky way around the email sender -

[cprecioso]

An update: The first usecase of configuring logging for Prisma was solved already by the introduction of prismaSetupFn https://wasp.sh/docs/data-model/databases#customising-the-prisma-client

[Martinsos]

Related to (and will probably be covered by, as it is a cross-concern):

• Improve DB / Prisma / Entities #2877
• Improve Auth #2875
• Improve Email Sender #2881
• Modular Wasp (Auth, Db, …) #2893