Deprecate ousd-analytics

[shahthepro]

The team has mixed opinions about this, so creating this issue to consolidate all the thoughts I have about this and get some feedback/comments about this

Why we should deprecate this project:

• Some of metrics and alerts overlap with the new Prometheus monitoring we have. It'd be easier and simpler to maintain one project rather than trying to maintain multiple projects that are supposed to do the same thing
• Some in the team can work in Python but almost everyone seems to be more comfortable with JS. This has cost us some engineering time with context switching
• We don't have any testing framework for this project despite every part of it being in-house. We have been following the "fix-forward" approach where we fix the bugs after it happens on production. This isn't ideal
• The DB Schema (while it works) might not scale well, IMO. For instance, OusdTransfer model stores all transfer events of OUSD and we do a some aggregation on that model (to find the number of unique wallets holding it and stuff). As data in the model grows, this is gonna slow down all queries and we will have to come back to optimize it

Possible blockers for deprecating:

• Prometheus monitoring doesn't do all of what this project does right now. We have to spend some time on getting that metric collection on par before we can deprecate
• Decide on what we do with the data in DB
• Figure out all services and frontends using the API exposed by this project and find an alternative way to do those

Potential options for blockers

• @rafaelugolini suggested using Dune for all the data queries
• For weekly and monthly reports, we could pull the data from Prometheus server (through a webhook or cron) and run it in a Lambda function
• Spend more engineering time during the (rumoured?) tech-debt sprint to get Prometheus monitoring do all of what this project does and backfill all the data in the DB

[micahalcorn]

Thanks for capturing this, @shahthepro. I too will believe tech debt sprint when I see it.

See also #305 for frontend concerns.