Proposal: Arb-subgraph refactoring

[DiRaiks]

Disclaimer: This is a proposal for the architectural restructuring and refactoring of some alerts-related code. I may lack complete context or understanding of the issues surrounding alert implementation.

Key Changes:

• Replaced Express with Fastify
• Utilized Plugins Instead of Various Functions and Classes
• Updated ENV Variables Configuration: Migrated configuration to the Fastify framework.
• Reduced Necessary Handlers: This might be specific to the provided alert example.

Some classes in the plugins (e.g., metrics) have been used as-is. However, any code structure can be used as needed. There is no strict requirement for using classes.

What is Fastify? Learn more about Fastify here.

Why Choose Fastify Over Express:

• Performance: Fastify offers better performance.
• Ease of Custom Plugins: Fastify facilitates the use of custom plugins throughout the application, simplifying the interaction of different alert components.
• Reusable Plugins: Plugins can be conveniently shared across different alerts, enabling the creation of a collection of reusable plugins.

Structure: arb-subgraph

• Plugins Directory: Located in the plugins folder.
• Reusable Plugins: Located in plugins/common.
• Constants: Set of constants for the alert.
• Utils: Set of utilities for the alert.
• main.ts: Main file where server initialization.
• env.ts: File for typing, describing, and configuring ENV variables.

Transferred from l2-bridge-arbitrum As-Is:

• Proto Folder/Files: (the reason for choosing this approach is unclear)
• Some Handler code sections

Example of Plugin Connection:

    fastify.register(fastifyEnv, ENV_OPTIONS),
    fastify.register(LoggerPlugin),
    fastify.register(ProviderPlugin),
    fastify.register(MetricsPlugin),
    fastify.register(HealthCheckerPlugin),
    fastify.register(BalanceCheckerPlugin),
    fastify.register(AlertsPlugin),
    fastify.register(ChainHandlerPlugin),
    fastify.register(GRPCServerPlugin),

Fastify also allows for convenient registration of server routes with custom handlers through plugins.

Example of Route Registration:

  await fastify.register(async (instance) => {
    instance.get('/metrics', instance.metrics.routeHandler())
    instance.get('/health', instance.healthChecker.routeHandler())
  })

Example Logs:

info: Logger plugin initialized
info: Provider plugin initialized with Arbitrum RPC provider
info: Metrics plugin initialized
info: HealthChecker plugin initialized
info: BalanceChecker plugin initialized
info: Alerts plugin initialized
info: ChainHandler plugin initialized
info: gRPC server plugin initialized
info: arb-subgraph is listening on 50051
{"level":30,"time":1722019537075,"pid":6517,"hostname":"MacBook-Pro-Andrej-2.local","msg":"Server listening at http://[::1]:3000"}
{"level":30,"time":1722019537076,"pid":6517,"hostname":"MacBook-Pro-Andrej-2.local","msg":"Server listening at http://127.0.0.1:3000"}
{"level":30,"time":1722019537076,"pid":6517,"hostname":"MacBook-Pro-Andrej-2.local","msg":"server listening on 3000"}
info: #arbitrum block: 236335474
info: handleBlock started at 21:45:42. Elapsed: 0.346 seconds

info: #arbitrum block: 236335475
info: handleBlock started at 21:45:42. Elapsed: 0.228 seconds

info: #arbitrum block: 236335476
info: handleBlock started at 21:45:42. Elapsed: 0.230 seconds

This pull request aims to improve the architecture and performance of the alerts system by leveraging Fastify's advanced features and plugin system. Your feedback and suggestions are welcome.