Split project / Monorepo

[tkvw]

I really like your solution, is it possible to split the project in a @warthog/core and @warthog/server package? I like to use it inside nestjs and don't need all the dependencies from the server requirements. Also, this would allow @warthog/nestjs?

[tkvw]

Something like: https://github.com/tkvw/warthog/tree/monorepo

[goldcaddy77]

Interesting idea. A few questions:

• Which pieces of Nest.js do you want that warthog doesn’t provide?
• What specific parts of Warthog would you be using? Ultimately we’d need a way to gather metadata from your project to add any of the auto-generation pieces
• Would you be ok if there was a reliance on TypeORM? I wasn’t planning on supporting other ORMs for a while

[tkvw]

• Which pieces of Nest.js do you want that warthog doesn’t provide?

• Maturity, nice separation of concerns, lots of tests, high involvement, good docs. For me there's no added value to have another DI framework.

• What specific parts of Warthog would you be using? Ultimately we’d need a way to gather metadata from your project to add any of the auto-generation pieces

• Generation of graphql types! Base resolvers. I come from rest, these are my first days of GraphQL. Because of the static schema, I thought: this is going to be a lot of repeat yourself code; this should be generated. Using a search criteria I came upon prisma, which I realized was just another orm, but with all the nice database features abstracted away. But I liked their idea of the static graphql types for filtering. In the github issues I saw a post from you mentioning this project, so that's why I am bothering you now 😄

• Would you be ok if there was a reliance on TypeORM? I wasn’t planning on supporting other ORMs for a while

• Yeah, that's the key part of warthog I like. I totally agree with your opinionated view. The decorators you've created to use in the Model, just feel right and there's not much value to generating types which are not bound to an orm. Not entirely sure it should be a peerDependency though.

[vadistic]

@tkvw As Proof of Concept I extracted some warthog logic and packed it as NestJS module: https://github.com/vadistic/nestjs-warthog

It works quite nice - see tests, but I have one big shizzle. Relations.

1. Without relations inputs and with them base services typings are half useless, because I wanted them for public api inputs.

2. I could add prisma-like {create: {}, connect: {})` logic, but then the result would be some sort of prisma1 clone build on top of TypeOrm. IS there any added value in this?

I would be really glad to hear what you think about it. I'm not convinced, but worst case scenario I think I can cut out few PR's from this endevour^^

EDIT:
Let me clarify my motivation a bit. It's not some shameless project plug. I'm on NestJS bandwagon, but I really like warthogs prisma-like approach. Esspecially since prisma2 moved away from this.

I could help refactor to monorepo and create nestJS module (or just encourage doing it?), but firstly I wanted to see if there's a point in this and after creating this limited demo I'm not so sure anymore. Waiting for some opinions :)

[thiagozf]

This would also allow Warthog to be used with something like apollo-server-lambda :)

[goldcaddy77]

Hey all, note that I'm planning on adopting a monorepo in V3!