-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove legacy backend #2777
Comments
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 |
@TueeNguyen would be great if you can shred some light on this. |
We're removing the backend instead of isolating it |
Since the legacy backend was removed, I think this is no longer needed. |
WE DID IT |
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:
src/legacy
test/
tosrc/legacy/test
src/backend
tosrc/legacy/src
package.json
insrc/legacy
package.json
that are specific to the legacy backend tosrc/legacy/package.json
(e.g., all dependencies for the backend should go in the root package).src/legacy
to the pnpm workspace listeslintrc.js
so it knows aboutsrc/legacy
test/jest.config.js
to point to the correct placeDockerfile
for the backend out of the root and intosrc/legacy/Dockerfile
src/backend
to point to the new locations.vscode/launch.json
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.The text was updated successfully, but these errors were encountered: