refactor(api): transform project to monorepo

[Dyostiq]

Substitute this line for a meaningful title for your changes

Overview

Please write a description. If the PR is hard to understand, provide a quick explanation of the code.

Designs

Link to the related design prototypes (if applicable)

Testing instructions

Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.

Feature relevant tickets

Link to the related task manager tickets

---

Checklist before submitting

• Meaningful commits and code rebased on develop.
• If this PR adds feature that should be tested for regressions when
  deploying to staging/production, please add brief testing instructions
  to the deploy checklist (docs/deployment-checklist.md)
• Update CHANGELOG file

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

marxan – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan/3cA4ZjHoodBwHWyASvRdFjCcxDnT
✅ Preview: https://marxan-git-feature-marxan-429-monorepo-vizzuality1.vercel.app

marxan-storybook – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/2w7Jct7mYtrjVZWKnfbDJ9qR7PYT
✅ Preview: https://marxan-storybook-git-feature-marxan-429-monorepo-vizzuality1.vercel.app

[Dyostiq]

I'll omit the test commit during the rebase

[hotzevzl]

@Dyostiq thank you! almost everything that I could check so far seems ok:

• build from clean-slate
• migrations
• seed-dbs
• unit tests
• e2e tests

Given that such a far-reaching reorganization can be hard to keep up to date for long as we keep merging other PRs, I would be keen to merge this sooner rather than later if nobody has strong concerns.

Given that "stuff seems to work", and especially that tests keep passing, I think that it should be easier to deal with any snags as they emerge, if at all, rather than trying to unearth any snags before merging.

[hotzevzl]

@Dyostiq thanks, this is awesome 🚀

All works ok from my point of view, I'd be keen to merge after confirming with the team tomorrow morning first thing that everyone is ok with rebasing their open PRs and adjusting paths 😱

We may want to revisit the Dockerfiles in a second moment to avoid copying into the container images source we may not need, but we'd need to do some work there in any case for production images, so I would not worry about this now.

[Dyostiq]

@hotzevzl
regarding copying not-needed files to the container – I believe we should copy there only an artifact of built code, and tsc/webpack compiles the required dependency graph, but it requires a Dockerfile rewrite (and maybe some fixes around workers). Now, with ts files in the container and with shared code possibility, we can't be sure what code is really needed.

[hotzevzl]

@hotzevzl
regarding copying not-needed files to the container – I believe we should copy there only an artifact of built code, and tsc/webpack compiles the required dependency graph, but it requires a Dockerfile rewrite (and maybe some fixes around workers). Now, with ts files in the container and with shared code possibility, we can't be sure what code is really needed.

yep, that's the plan as we move towards proper staging and eventually prod deployments - I'll likely do a multi-stage Docker image build