Nest Monorepo vs Turborepo for shared code and serverless bunde

[hollow vault]

Considering a refactor to the existing monolith at the moment. We have a big Nest app and would like it to instead be comprised of multiple smaller lambdas with lazy loaded modules/services, bundled with swc or webpack. It will continue to serve as a graphql backend to multiple react-dom and react-native applications (think cms, a user-facing app, and internal apps that speak to the same gql api) and could therefore hugely benefit from code reuse.

Namely, the idea is to make Zod schemas be the source of truth that can be used for scaffolding the database schema, graphql inputs and object types (for automatic complex validation), and frontend validation.

I've sandboxed a working turborepo proof of concept last year that actually worked fantastically with good modular tsconfigs and eslint, a couple of ts packages that were imported into two mock services (back and front) and I was satisfied that this was the direction to go. Now picking it back up, of course I did not mock the backend service using nest, and instead just a thin fastify file. Nest no like. The shared libs have to be compiled first and won't trigger a recompile. Other fails include discovering that tsconfig.references is no go. Esbuild does not support decorators. Finding chatter about Nest being very sensitive to versions of packages for some reason (I don't get this deeply at the moment, but it seems like a big problem to walk into at a later stage - is that real?).

What are our options here? I can see that Nest has its own take on a monorepo that is well supported by nest-cli, but strays from what would be a more generic structure that suits us very well. Nest is currently the big boss in our project, but it would be nice that commonly shared code was agnostic with the monorepo structure mirroring that: turborepo succeeds here.
Should I use my own from-scratch webpack config for development, that I could then also reuse for deployment?

I hope I am getting my Q across, head is spinning atm

[orchid rapids]

@hollow vault - You sound like you are quite advanced in your experience. So, knowing that alone, I can guarantee you'll not at all be happy with Nest's monorepo mode.

Can you voice your main concern or problem? I see a lot of issues above, let's try and tackle them one at a time.

[hollow vault]

Thanks for taking the time Scott. My main concern is "/gestures broadly at monorepos" I guess.
Since I started the thread, I saw @calm valve advocating for nx and gave it a try in the integrated mode. It actually works well with nest which was a pleasant surprise (editing shared libs reloads the app, go to definition works), but find references / rename symbol / LSP refactoring does not work, I am wondering if any of you guys have experienced this / solved it? May not be a nest issue but if people here are running it successfully I might be doing something wrong. I got this same result from creating a new integrated workspace with nx, as well as using the official nx-recipes nestjs-prisma example. Everything other than this is far better than turborepo/nest monorepo so really hoping it's my fault somehow. Cheers!

[calm valve]

Yeah, references are the one issue I have, but I think it's an LSP limitation, as the LSP is looking for references within the imported and exported paths up to the library's root, but not in aliased psth (i.e. package imports). I usually justg use my global search and call it good'

If you wanna see my current side project, I can drop a link. Does a lot of custom stuff in terms of security (no package for csrf or auth, just self-implemented for knowledge purposes) and a pipe for validation using zod instead of class-validator.

Also (will soon have) an "empty" project for a custom postgres image in docker to use a ulid extension. The project honestly has a lot of fun stuff to it and I've still got a ways to go

[hollow vault]

ohh that is awesome. A confirmation of a problem with a nice-to-have is as good as a solution for it. Thanks bud

and Id absolutely devour any repo you throw at me, I can learn a lot from someone like yourself that knows nest intimately, absolutely. Have you tried bundling any of this for lambda or heard any horror stories? Have experienced a lot in the past with symlinked deps needing special handling, yada yada by the time you're done you've created an absolute monster that is hard to keep updated

[calm valve]

Personally, I've stayed away from serverless/lambda/edge functions/etc. Never found a proper use case for them with a framework like Nest. I'd rather have full control over my server environment if possible

https://github.com/jmcdo29/unteris (there's a huge PR that I'm gonna merge soon that has the custom postgres project because I was waiting on the extension to publish their 0.1.2 update which fixed an issue with joins and the postgres hash commutator, just gotta write tests for it)

[hollow vault]

Thank you! Would I be able to ping you if i have any questions, not to treat you like support but just as a quick litmus test like my issue above since you turn up for every single related search ive done here hahahah

[calm valve]

As you've asked first and cleared it with me, yeah, that's all right. I'm a pretty big advocate for Nx as I feel they've provided one of the most comprehensive monorepo tools in the JS community. Their Slack is another great reference if I'm not available

[hollow vault]

also, sls makes sense from the business perspective. I agree if you take it in aggregate it is less compelling. But when you are working with funds and team with a potential span of possibilities for the next 12mo being anywhere between unwound company or 1m+ users and rapid hiring, it is the sanest way to build

overbuilding k8s on a 1-5% success chance is a waste of time, but not having anything ready for that success chance means you fumble it and why were you even working on it if you did not believe it could happen - is a good summary I guess