Shared Packages about angular-graphql-nestjs-postgres-starter-kit

[cloudkompute]

Hi Alexi

Could you pl. let us know whether this feature is going to be released in near future? Is there possibility that the app. supports SSR?

Thanks

[alexitaylor]

Hi @johannesschobel ,

I like the idea of a shared package between the client and the server, but I have a few concerns.

1. How would you include this shared package in the front-end build and then in the back-end build? As currently those are two separate processes and I would like to keep it like that. Maybe creating a private NPM package then importing it into both projects could work.

2. What if a dev wants to swap out the NestJS backend for a Java one? Then this shared package is only useful for the front-end.

3. Also, the argument is best to have a separation of concern between the BE and FE, or is it an anti-pattern?

What I would like to have eventually is a code generator that will generate boilerplate code like models, basic GraphQL queries and mutations, and FE code from a defined model/interface file. Something similar to how Liquibase manages a database from changelog files. This will avoid the need for developers to create and maintain boilerplate code like shared models and interfaces.

Thank you for your interest in the project.

Alexi Taylor

[johannesschobel]

Dear @alexitaylor ,

thanks a lot for your reply and sharing your thoughts. Maybe you can look into narwal to see how they try to solve this issue. Basically, they have apps and libs (shared "libraries") that are consumed from the apps. All parts (apps & libs) are built as dedicated npm packages, and are bundled via lerna. To be more precise, lerna symlinks the packages internally as dependency - thats all.

For example, if your @app/frontend package and your @app/backend package both like to use the @app/models package, you would add the latter as a dependency in their package.json file.. then you run something like lerna bootstrap and lerna "magically" adds those dependencies to the npm_modules of respective packages - thats all..

Regarding your points against it:

1. While this is a good idea - it only works if you have a "stable code base". For example, during the development process (within a "larger" team; people > 1), this results in a huge workload. Because you would need to change something, push it to git, push it to npm, the other needs to download it, and so on.. In development process this is a huge (!) issue, i think. Lerna, in turn, allows to separately push packages to npm if you would like to share those packages as independent modules as well..

2. that is true - but it would be in the case of developing a "shared package that is separately pushed to npm" as well.. However, you may need to think of those packages as a possibility to let other developers communicate with your api as well. The package (which contains, for example, interfaces for request / response objects) may be used by other devs as well.

3. SoC is good, yeah, but i don't see why you would violate this rule here?

All the best and thanks a lot for your time & effort!

[alexitaylor]

Working on solution to use NX to create a shared libs package for models/interfaces to be shared between the BE and FE.

_{Sent with GitHawk}

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days