Split api into chain related/unrelated apps

[ygrishajev]

Problem Statement

Our current API architecture consolidates both chain-specific features and unrelated functionalities (e.g., user management) into a single API. This creates ambiguity and complicates our deployment process, resulting in the following environments:

1. staging - mainnet
2. staging - sandbox
3. production - mainnet
4. production - sandbox

While this structure works for chain-specific logic, it introduces unnecessary complexity for non-chain-specific functionalities, such as user management.

Proposal

To resolve this, we propose splitting the current API into two distinct projects:

• Chain-specific API: Focused on features related to the blockchain.
• General API: Handling non-chain-specific logic like user management.

Deployment Strategy

• General API:
  • Deploy to 2 environments (staging, production).
• Chain-specific API:
  • Deploy to 4 environments (staging-mainnet, staging-sandbox, production-mainnet, production-sandbox).

Tasks

• Split out the chain-specific logic into a separate app.
• Deploy the chain-specific app to the staging environment.
• Test the functionality of the new chain-specific app.
• Remove the chain-specific logic from the existing API.

Benefits

This change will:

• Reduce ambiguity in our API architecture.
• Simplify deployments and management of non-chain-specific features.
• Provide clearer separation of concerns, making the system more maintainable.

Additional Considerations

• Ensure that existing deployments remain functional during the transition.
• Plan for a smooth migration to the new architecture with minimal downtime.

[baktun14]

Yea, this makes sense.

[Oyase-shinobi]

Hello
Happy weekend
I would love to engage in your team and contribute in this project