When all your code is JS you often want to share code between the frontend and backend there should be a canonical recommended way of doing this.
Motivation
Prevent N app owners from reinventing solutions to this basic issue.
Detailed proposal
There are three approaches:
one way copying from one side to another
going through all the work of creating a true node package and publishing to an internal registry
creating a "common" package you can easily build that lives co-located with the varies client "sides" but is side agnostic but still knows about shared information -- such as GQL types
The Common Package
We considered these options and ended up with the 3rd for a few reasons. For one, I've seen at scale that copying code around breaks all the time because you end up with the gorilla and the bananna problem where the code soaks up dependencies from it's native environment (that can't or should not be shared).
For purely hygiene purposes it makes sense to dependency break (explicitly) any code that is shared so that leakage is prevented. A common package is nice for this.
For stuff already copied from the backend to the frontend i.e. the GQL types -- you simply build the API side first and copy it into the common package and move on with your life.
One other note is whether common should be one giant grab bag or a set of discreet packages -- I think the former is reasonable. If you want to partition packages further for some reason you can do so. The goal is to solve the common issues folks run into weeks or days into a project and that could work well for years.
Example RW Dir
/api
/web
/common
Build Order
GQL types -> common -> api -> web
Implementation
We simply build it as a local only package.
Could use advice on copying the types over, for now part of LeftLane's run script just copies in the types at build time:
'./node_modules/.bin/rw-gen && cp web/types/graphql.d.ts packages/utils/src/graphql.ts && yarn workspace @leftlane/utils run build',
Summary
When all your code is JS you often want to share code between the frontend and backend there should be a canonical recommended way of doing this.
Motivation
Prevent N app owners from reinventing solutions to this basic issue.
Detailed proposal
There are three approaches:
The Common Package
We considered these options and ended up with the 3rd for a few reasons. For one, I've seen at scale that copying code around breaks all the time because you end up with the gorilla and the bananna problem where the code soaks up dependencies from it's native environment (that can't or should not be shared).
For purely hygiene purposes it makes sense to dependency break (explicitly) any code that is shared so that leakage is prevented. A
common
package is nice for this.For stuff already copied from the backend to the frontend i.e. the GQL types -- you simply build the API side first and copy it into the
common
package and move on with your life.One other note is whether common should be one giant grab bag or a set of discreet packages -- I think the former is reasonable. If you want to partition packages further for some reason you can do so. The goal is to solve the common issues folks run into weeks or days into a project and that could work well for years.
Example RW Dir
Build Order
GQL types -> common -> api -> web
Implementation
We simply build it as a local only package.
Could use advice on copying the types over, for now part of LeftLane's run script just copies in the types at build time:
'./node_modules/.bin/rw-gen && cp web/types/graphql.d.ts packages/utils/src/graphql.ts && yarn workspace @leftlane/utils run build',
For example:
Are you interested in working on this?