Merge metriq-app and metriq-api repositories

[cosenal]

I see no value in keeping backend and frontend of the Metriq website in two separate repositories.

Some general thoughts here:
https://softwareengineering.stackexchange.com/questions/417953/should-frontend-and-backend-be-on-separate-github-repos

Some symptoms that having two repositories is awkward:

1. Deploying involves keeping the two repos in sync, through the git submodule mechanism, which is never ideal.
2. it was confusing to have 2 repos for one UnitaryHACK projects, and hackers had to do PRs in both repos anyway.
3. CI/CD will be easier to implement if everything was in one repo Dockerize metriq-app+metriq-api #236

Opinions? @bachase @vprusso @natestemen

[bachase]

My usual rule of thumb is to keep things in the same repo that you typically release together and/or change together. The benefit of separation is to make independent change easier. It sounds like these two are in that former camp? If so, definitely support merging.

[vprusso]

I second @bachase here and support the decision to merge the projects!

[natestemen]

No blockers from me to create the monorepo.

[cosenal]

One small "marketing" downside I spotted is that we would lose the stars on metriq-app (31) if we merge it inside metriq-api. Perhaps is a small cost to pay. And in the long term, we would have one repository to star, which is good for engagement.

[bachase]

Would it work to merge the other direction to retain the stars?

[natestemen]

On the plus side, renaming the repo metriq.info might get more stars on it. For example, who stars an api repo?

[cosenal]

Exactly, that was my point about long term engagement. It will also make it easier to file issues. Why a user needs to bother about whether the issue is in the api, in the frontend, or in the database (we have another repo for that too 🤦🏻‍♂️)

[cosenal]

Merge completed. The new monorepo is at https://github.com/unitaryfoundation/metriq-web

Benefits of the merge:

• Frontend and backend now live together, no more painful management of submodules.
• Update frontend and backend in the same PRs when contracts change. No more manual syncing of api and app.
• Easier maintenance: shared tooling, linting, and dependencies managed in one repo (we already benefitted of this when setting up the ruleset of the metriq-web repo)
• Cleaner CI/CD (later): we will set up a proper deployment and development process based on Docker.
• Reduced confusion: new contributors no longer have to decide which repo to open issues/PRs in. We noticed this pain point during the last unitaryHACK.
• Visibility: one repository to star, one repository to link in marketing announcements, etc.