Single-service API on SQL Database
Run every endpoint of an API in one function that reads and writes SQL Database, with Cache for the responses that allow it.
This design serves teams that ship their API as one deployable unit. The application routes the API’s paths to one function that implements every endpoint and reads and writes SQL Database, with KV Store for sessions or configuration, and Cache stores the responses that allow it. The design implements the use case Build REST and GraphQL APIs.
Architecture diagram
Read the diagram from the function outward. Every request the application receives runs the same function, so the function is the one place that knows every endpoint. From there, the paths split by what the endpoint does: a response that every client may share goes to Cache, a read goes to a replica of the database, and a write goes to the main instance. KV Store sits beside the database for values read by key, such as a session, and the design works without it. Real-Time Metrics reads what the application records and changes nothing on the request path.
Dataflow
- A client’s request reaches the application on the API’s domain, and a rule of the application runs the API function.
- The function matches the method and the path to an endpoint, and answers a path it does not serve with an error.
- A read opens a connection to a read replica of the database, which takes the database name and no token, so the data a read needs stays inside Azion.
- A write goes to the main instance through the Azion API, because the main instance is the only one that applies writes. The replicas then hold the change.
- A response that every client may share is stored in Cache, and later requests for it are answered from the stored copy until it expires or the function removes it.
- One function and one database serve the whole API, so a deploy, a rollback, or a schema change reaches every endpoint at the same moment.
Components
- application: the Platform Resource that receives the API’s requests on its domain and routes them to the function with a Rules Engine rule.
- Functions: one function implements every endpoint. A deploy replaces the code of all the endpoints together, which is what makes the API one unit.
- SQL Database: holds the API’s relational data. A function reads through a read replica with no token, and writes go to the main instance through the Azion API with a personal token.
- KV Store: holds sessions and configuration read by key, a design option. It is eventually consistent and has no compare-and-set, so it carries values that tolerate a short delay, not the API’s records.
- Cache: stores the responses that every client may share, such as a list or a lookup, so a repeated call skips the database read.
- Real-Time Metrics: reports the API’s request time and status codes by domain, and the number of times the function ran.
Implementation
- Build REST and GraphQL APIs - builds this design end to end: the database, the function’s write credentials, the API function with its cached list, and the checks for each.
- Build a RESTful tasks API with Functions and SQL Database - implements the endpoints of the function with the Hono router.
- Deploy a function with Azion CLI - creates the project, the application, and the function instance that serve the API.
- Create and manage databases - creates the database the function reads and writes.