telescope
telescope copied to clipboard
Seneca-CDOT
Remove legacy backend
As we prepare to migrate away from the legacy backend, and toward a pure microservices approach, I'd like to switch the repo around a little bit. Specifically:
- create
src/legacy - move
test/tosrc/legacy/test - move contents of
src/backendtosrc/legacy/src - create a
package.jsoninsrc/legacy - move all aspects of the root
package.jsonthat are specific to the legacy backend tosrc/legacy/package.json(e.g., all dependencies for the backend should go in the root package). - add
src/legacyto the pnpm workspace list - update
eslintrc.jsso it knows aboutsrc/legacy - update
test/jest.config.jsto point to the correct place - Move and update the
Dockerfilefor the backend out of the root and intosrc/legacy/Dockerfile - update any references in docs or other files that use
src/backendto point to the new locations - update relative links from tests or other source files, so things still work
- update
.vscode/launch.json - etc
When this is done, it's going to be easier to use turborepo, since all of our projects will be workspaces, and there will be nothing in the root except our tooling.
It will also mean that all of our sub-projects will use the same general layout, with their own src, test, Dockerfile, etc.
Later, we'll be able to dump src/legacy as a whole.
This sounds like alot of work that's really unnecessary. The only service blocking the backend folder from being deleted is the parser service. I get wanting to make more use of turborepo, but considering it'll eventually be deleted, this just sounds like work we can ignore no?
It's a fair question. The reason I think that this is a valuable exercise is that it helps the current team to define the boundaries of the old vs. new code. Doing this work will be necessary in order to remove the old code, and if we don't know where it is, it's hard to do. Getting rid of the backend isn't quite as simple as turning on the parser service and deleting src/backend, as you can see above.
