Build-Out Stand-Alone Flow API Service

[AliSMAmin]

Context

This Epic is concerned with the Flow API Service component, a part of the Flow Access Node Refactoring .

Proposed Solution

The Flow API Service is externalized and will serve the existing Access API, run as its own standalone process. The separation of the Flow API from the existing Access Node enables options for horizontal scaling at the request level and other possibilities such as routing, rate limiting, spam protection and caching in the new component if desired.

Step Definitions

• Create stand-alone service which can initialize on its own
• Point it to an Access Node or Observer upon bootstrap

Definition of Done

• Go run from API Service folder runs Flow_api_service.go
• Flow_api_service.go successfully initializes independent Flow API Service

[AliSMAmin]

Behavior-Driven Design Spec

Title: Bootstrapping Flow API Service
Feature: the Flow API Service can be bootstrapped like any other service from Flow-Go’s cmd package
Narrative:
As a: Flow Blockchain Data Service Operator
I want: a standalone Flow API Service
So that: it can proxy API calls between DPS API, Protocol API, and Execution Data API

# Notes: fleshing out Flow API Service will require multiple issues

Background: Joshua is an Observer Service and DPS operator
Given: DPS utilization of streaming and streaming functionality on the Protocol/Execution State API
When: user runs Go build from API Service folder under cmd/
Then: Flow_api_service.go runs and builds a standalone Flow API Service entity

[miklosszegedi]

Thank you, @AliSMAmin for the proposal.

1. One essential question is what makes a service a service and not a node. I suggest adding specifications of limited configurability, and bounder memory usage.
2. Services still run in a docker container.
3. It is important to note, that this service helps scaling, and support. While any flow network will have a balanced input and output flow in the long run, this service can add more read traffic.
4. It is probably a good idea to assess whether a unified (protocol + execution) cache storage solution is sufficient, to help to reduce the efforts.

[miklosszegedi]

Initial PR to discuss: GetElastech/api-service#1

[miklosszegedi]

We are working on the prototype here: https://github.com/GetElastech/api-service

[ruthelastech]

Agreed with Dapper that this will not be merged until the entire Flow API service is built out. We can mark the scope of this task as Done. We can follow up on the final merge when all subsequent issues are completed.