Thoughts, Roadmap, Production Ready

[infnada]

I'm pretty new here and i like to "learn by doing", so i started investigating how current cardano explorers operate and trying to find what they use to fetch cardano's blockchain information.

After some digging i came across with this repository, i did some PoCs and i don't think cargano-graphql is a "production ready" product.

I will try to expose my concerns and why it seems that current ada-explorers don't use graphql but instead they use of pure SQL* with the help of https://github.com/blockfrost/blockfrost-backend-ryo/tree/master/src/sql
* That's a guess based on the information they are able to show on their websites but it doesn't seem to be currently available through cardano-graphql schema.

As this repository seems to be an official way of querying cardano-db-sync information i would really love to have some improvements to mark it suitable for production environments.

Production Ready Tasks:

1. ApolloServer needs to be decoupled from many services as possible
   • If the cardano-node/ogmios CardanoNodeClient goes offline or it's not reachable on initialization we need to still be able to query the PSQL DB trough Hasura+Apollo.
     • Any major issue on cardano-node/cardano-db-sync where a full resync (or backup restore) is necessry from our side (application operator perspective), could lead to a lot of downtime to any application using cardano-graphql
   • ApolloServer has a dependency on CardanoNodeClient to calculate the current sync % (getTipSlotNo). The fallback (error throw) when CardanoNodeClient is not initialized i think is already handled by the code
   • This also will help on development since we will not need a cardano-node + ogmios + cardano-db-sync 24/7 when developing an application.
     • Ex: I'm currently on a vacation trip and i'm unable to start a full "development kit" on a 8GB laptop. But i should be able to start a PSQL+Hasura+Apollo and keep working with "old synced" data

1.2. ApolloServer should be able to be deployed on multiple instances for HA/performance
- Currently cardano-graphql has a lot of intra-dependencies. ApolloServer should only require connectivity with Hasura/PSQL through HasuraClient.

2. HasuraClient migrations should run only once or on-demand.

   • Since we need 1.2., performing a migration down -> up every time we start cardano-graphql / ApolloServer is not feasible.

3. I didn't check a lot of what MetadataClient, ChainFollower and Worker but they seem to work together as a metadata fetcher (assets, pools,.. ?)

   • To accomplish 1.2. without a lot of pain or rebuild, i think we should separate getters (ApolloServer + Harusa) from setters (Metadata, ChainFollower, Worker) into two independent services/containers

4. This could be demanding if running multiple instances of getters https://github.com/input-output-hk/cardano-graphql/blob/master/packages/api-cardano-db-hasura/src/HasuraClient.ts#L178

   • Maybe this can be handled by the setters and maintain the state in another PSQL table/view. I would not like to overcomplicate thing by introducing queues, redis, ...

5. We should be able rewrite https://github.com/blockfrost/blockfrost-backend-ryo/tree/master/src/sql into graphql. Example things i miss during my PoCs;

   • graphql.schema TransactionOutput doesn't include a reference to tx_out.stake_address_id (stake_address.view) only to a tx_out.address. I didn't find a way to get all the PaymentAddresses managed by a StakeAddress without this reference
     • This could even be in a separate table/view
   • graphql.schema scripts Script_bool_exp doesn't allow to search by script hash.
   • graphql.schema rewards of type reserve, treasury doesn't include a reference to its tx_hash, would be cool to have it (or be able to get them directly when getting a Transaction) like https://github.com/blockfrost/blockfrost-backend-ryo/blob/master/src/sql/accounts/accounts_stake_address_mirs.sql
   • others like query pool metadata information (pool name for example). We have setters that are continuously fetching metadata data but there's no way to query it with graphql pool_offline_data

I may want to help on some of these issues if requested, but first i would like to know if this project "has resources" from IOHK or if it may be deprecated in following months by other tool/s. Is there any roadmap for this?

Thoughts? tyty