Decouple chainquery data access from the database and chainquery daemon

[anbsky]

I propose implementing a rate-unlimited HTTP GraphQL API for accessing the data.

For example, to retrieve a claim by claim_id, request:

query {
  Claim(claim_id: "6769855a9aa43b67086f9ff3c1a5bacb5698a27a") {
    fee
    sd_hash
  }
}

Response:

{
  "data": {
    "Claim": {
      "fee": "0.0",
      "sd_hash": "d5169241150022f996fa7cd6a9a1c421937276a3275eb912790bd07ba7aec1fac5fd45431d226b8fb402691e79aeb24b"
    }
  }
}

Authorization to lift rate limits can be done via Authorization HTTP header.

[tiger5226]

@tzarebczan said @nikooo777 was going to solve the problem a different way. Can this be closed then if its no longer needed?

[anbsky]

If that different way involves talking directly to the mysql, like lbrytv UI code currently does, I'd still prefer to have a proper API. @nikooo777 ?

[nikooo777]

There are countless of softwares out there that talk to chainquery through a mysql connector already. Moving away from that or coming up with yet another API will not solve anything imho. If we really really want to use the public api then I'd suggest refactoring it so that it has no limits on the number of queries it can run per hour and/or just add http.auth.

On Thu, Apr 23, 2020, 11:59 Andrey Beletsky [email protected] wrote:

If that different way involves talking directly to the mysql, like lbrytv UI code currently does, I'd still prefer to have a proper API. @nikooo777 https://github.com/nikooo777 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lbryio/chainquery/issues/148#issuecomment-618306695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMVSERCZCM35LZUTYZDELROAGPPANCNFSM4MODRULA .

[anbsky]

Dragging mysql dependencies, credentials and coupling through countless softwares sounds like a terrible idea and a disaster waiting to happen. Least we can do is to avoid that in new software we create.

[anbsky]

To elaborate on the kind of trouble that we're inviting, mysql is a very complicated piece of software, containing almost a thousand of known remote vulnerabilities. This is why it is an extremely bad practice to expose it over internet, especially in production.

As for whether having any kind of working API would solve anything or not, I see a few problems solved simply by getting rid of the need to create and maintain a pool of mysql connections and write several lines of raw SQL by hand just to make a simple query.