From 87c9668903bf18fd04b65b02c11c3369e2489e2d Mon Sep 17 00:00:00 2001 From: iamvigneshwars Date: Wed, 3 Jul 2024 11:06:06 +0000 Subject: [PATCH] add stableRevision and nightlyRevision to values, and enable auto-sync for stable release --- charts/apps/Chart.yaml | 2 +- charts/apps/templates/nightly.yaml | 4 +- charts/apps/templates/stable.yaml | 4 + charts/apps/values.yaml | 2 +- charts/supergraph/Chart.yaml | 2 +- .../schema-configmap.yaml | 0 docs/explanations/federation.md | 42 ---- docs/how-tos/python_service.md | 183 ------------------ docs/index.md | 4 - docs/references/terminology.md | 15 -- docs/requirements.txt | 1 - 11 files changed, 9 insertions(+), 250 deletions(-) rename charts/supergraph/{template => templates}/schema-configmap.yaml (100%) delete mode 100644 docs/explanations/federation.md delete mode 100644 docs/how-tos/python_service.md delete mode 100644 docs/index.md delete mode 100644 docs/references/terminology.md delete mode 100644 docs/requirements.txt diff --git a/charts/apps/Chart.yaml b/charts/apps/Chart.yaml index feb563b..9486e0b 100644 --- a/charts/apps/Chart.yaml +++ b/charts/apps/Chart.yaml @@ -2,4 +2,4 @@ apiVersion: v2 name: graph description: ArgoCD Apps used to deploy the Graph type: application -version: 0.1.1 +version: 0.2.0 diff --git a/charts/apps/templates/nightly.yaml b/charts/apps/templates/nightly.yaml index aca778e..1700d75 100644 --- a/charts/apps/templates/nightly.yaml +++ b/charts/apps/templates/nightly.yaml @@ -9,7 +9,7 @@ spec: project: {{ default .Release.Namespace .Values.project }} sources: - repoURL: {{ .Values.graph.repoURL }} - targetRevision: {{ .Values.graph.targetRevision }} + targetRevision: HEAD path: {{ .Values.graph.path }} helm: valuesObject: @@ -45,7 +45,7 @@ spec: path: /nightly - repoURL: {{ .Values.schema.repoURL }} chart: {{ .Values.schema.chart }} - targetRevision: 0.1.1 + targetRevision: "*" destination: name: {{ .Values.destination.name }} server: {{ .Values.destination.server }} diff --git a/charts/apps/templates/stable.yaml b/charts/apps/templates/stable.yaml index 969b59f..ceaf2b0 100644 --- a/charts/apps/templates/stable.yaml +++ b/charts/apps/templates/stable.yaml @@ -43,3 +43,7 @@ spec: name: {{ .Values.destination.name }} server: {{ .Values.destination.server }} namespace: {{ default .Release.Namespace .Values.destination.namespace }} + syncPolicy: + automated: + prune: true + selfHeal: true diff --git a/charts/apps/values.yaml b/charts/apps/values.yaml index 40dea4e..44ddbc4 100644 --- a/charts/apps/values.yaml +++ b/charts/apps/values.yaml @@ -12,7 +12,7 @@ graph: schema: repoURL: ghcr.io/diamondlightsource/graph-federation-supergraph - targetRevision: 0.1.1 + targetRevision: 0.1.2 chart: supergraph destination: diff --git a/charts/supergraph/Chart.yaml b/charts/supergraph/Chart.yaml index 39fe0cb..7257836 100644 --- a/charts/supergraph/Chart.yaml +++ b/charts/supergraph/Chart.yaml @@ -1,3 +1,3 @@ apiVersion: v2 name: supergraph -version: 0.1.1 +version: 0.1.2 diff --git a/charts/supergraph/template/schema-configmap.yaml b/charts/supergraph/templates/schema-configmap.yaml similarity index 100% rename from charts/supergraph/template/schema-configmap.yaml rename to charts/supergraph/templates/schema-configmap.yaml diff --git a/docs/explanations/federation.md b/docs/explanations/federation.md deleted file mode 100644 index 7fb576f..0000000 --- a/docs/explanations/federation.md +++ /dev/null @@ -1,42 +0,0 @@ -# Federation - -## Preface - -API federation facilitates providing access to data from numerous underlying services via a single endpoint. This hides the complexity of the underlying implementation from clients. - -There are numerous methodologies for federating between GraphQL services. The Graph utilizes [Apollo Federation v2](https://www.apollographql.com/docs/federation/subgraph-spec/) which is the most widely adopted, supported, and featureful of the methods. - -## Schema Composition - -In order to compose the federated API each of the comprising services must supply a [Subgraph Schema](../references/terminology.md#subgraph-schema), which are then stitched together in order to form the [Supergraph Schema](../references/terminology.md#supergraph-schema). The Subgraph Schemas act as the source of truth for the API, whilst the composed Supergraph Schema is used by the Router to perform query planning, and by clients who are making requests against the federated API. - -Subgraph Schema registration for the Graph is performed by adding a schema file to the [schema directory of the graph-federation GitHub repo](https://github.com/DiamondLightSource/graph-federation/tree/main/schema). A continuous integration job will then build the Supergraph schema. - -## Request Routing - -At run time a proxy service known as the Router receives API requests, plans queries according to the [Supergraph](../references/terminology.md#supergraph) schema, queries the appropriate services, and constructs the response. The query planning stage allows the Router to optimally query the underlying service, taking into account any dependencies which may exist between services. - -An exemplary query sequence diagram is shown below, in which the queries to services B and C are dependent on the result of the query to service A. - -```mermaid -sequenceDiagram - participant Client - participant R as Router - participant A as Service A - participant B as Service B - participant C as Service C - Client->>R: Request - activate R - R-->>R: Query Planning - deactivate R - R->>A: Request - A->>R: Response - par - R->>B: Request - B->>R: Response - and - R->>C: Request - C->>R: Response - end - R->>Client: Response -``` diff --git a/docs/how-tos/python_service.md b/docs/how-tos/python_service.md deleted file mode 100644 index 46f5741..0000000 --- a/docs/how-tos/python_service.md +++ /dev/null @@ -1,183 +0,0 @@ -# Python Service - -## Preface - -This guide will explain how to develop a Python service to serve data to the Graph. -We will cover: - -- Setting up the HTTP/GraphQL Server in [Serving GraphQL Requests](#serving-graphql-requests) -- Creating GraphQL Objects and providing field resolvers in [Defining Objects](#defining-objects) -- Exporting the GraphQL schema for use in federation in [Schema Generation](#schema-generation) - -## Dependencies - -This guide will utilize the following dependencies: - -- `uvicorn` as the HTTP server -- `starlette` as the HTTP framework -- `strawberry-graphql` with the `asgi` feature for GraphQL request handling - -## Serving GraphQL Requests - -To begin we will create a placeholder GraphQL `strawberry.federation.Schema` with an empty list of `types` and with `enable_federation_2` set to `true`. -From this we will create a `strawberry.asgi.GraphQL` request handler, which will process requests for a given route and generate responses. - -To route and handle HTTP traffic we will create a `starlette.application.Starlette` app. -We will call `add_route` on the app to register a HTTP route with the aforementioned `GraphQL` handler. -This will in turn be served using a `uvicorn` server with `uvicorn.run`. - -!!! example "GraphQL Request Handler" - - ```python - import uvicorn - from starlette.application import Starlette - from strawberry.asgi import GraphQL - from strawberry.federation import Schema - - SCHEMA = Schema(types=[], enable_federation_2=True) - - if __name__ == "__main__": - app = Starlette() - app.add_route("/graphql", GraphQL(SCHEMA)) - uvicorn.run(app) - ``` - -!!! tip - - The `OpenTelemetryMiddleware` from `opentelemetry-instrumentation-asgi` can be added to the `Starlette` app with `add_middleware` to provide route level tracing and metrics. - -## Defining Objects - -!!! info - - See the [Strawberry schema basics docs](https://strawberry.rocks/docs/general/schema-basics) for a full explanation of how to implement various objects and resolvers. - -Strawberry creates GraphQL Objects from Python classes, hence creating a GraphQL Object is as simple as creating a Python class and tagging it with `@strawberry.type`. -Methods may be used to provide derived fields or supply related objects as described in the [Standalone Objects](#standalone) and [Related Objects](#related) sections. -Objects from other services may be extended as described in the [Federated Objects](#federated) section. - -### Standalone - -!!! warning - - Standalone object creation is only shown for completeness, it is strongly recommended to define your object in relation to an existing object in the Graph where possible. - -A standalone object can be created simply by defining a `class` with the `@strawberry.type` tag with various properties. -These properties must be given [type hints](https://docs.python.org/3/library/typing.html), which will be used to inform (de)serialization of the object and provide API guarantees. -The `strawberry.Private` type can be used to hide a given property from the API. - -Additionally, you may define resolvers which are used to compute a field in the GraphQL response, according to some input. -Such resolvers can be defined as methods on the class with the `@strawberry.field` tag which return a known type. -They may take additonal input arguments which modify the way they operate. - -!!! example "Standalone Object" - - ```python - import strawberry - from typing import Optional - from uuid import UUID - - PEOPLE: dict[UUID, Person] = populate_people() - - @strawberry.type - class Person: - id: strawberry.Private[UUID] - first_name: str - last_name: str - preferred_name: Optional[str] - - @strawberry.field - def name(self) -> str: - return self.preferred_name if self.preferred_name is not None else f"{self.first_name} {self.last_name}" - ``` - -### Related - -Using resolvers, as with derived properties in [Standalone Objects](#standalone), we can define related objects. -These are simply methods with the `@strawberry.field` tag which return another object `class`. -Similarly they may take additional arguments, which are often used for filters or pagination parameters. - -!!! example "Related Object" - - ```python - import strawberry - from uuid import UUID - - PEOPLE: dict[UUID, Person] = populate_people() - PETS: dict[UUID, Pet] = populate_pets() - - @strawberry.type - class Person: - id: strawberry.Private[UUID] - - @strawberry.field - def pets(self) -> list[Pet]: - return [pet for pet in PETS if pet.owner_id == self.id] - - @strawberry.type - class Pet: - id: strawberry.Private[UUID] - owner_id: strawberry.Private[UUID] - - @strawberry.field - def owner(self) -> Person: - return PEOPLE[self.owner_id] - ``` - -### Federated - -!!! info - - See [the Strawberry federation docs](https://strawberry.rocks/docs/guides/federation) for a full explanation of how various federation mechanisms can be implemented. - -Objects from other services in the federated Graph can be referenced by creating a `class` tagged with `@strawberry.federation.type(keys=...)` where `keys` is a list of names of primary keys for the type. -If your `class` contains parameters which do not come from the `keys` then you must define a `resolve_reference` `@classmethod` which produces an instance of your `class` when given the `keys`. - -Once a federated Object is defined you can implement resolvers for it as with a [Standalone Object](#standalone) by defining a method with the `@strawberry.field` tag. - -!!! example "Federated Object" - - ```python - import strawberry - from uuid import UUID - - @strawberry.federation.type(keys=["id"]) - class Pet: - id: strawberry.Private[UUID] - toy_ids: strawberry.Private[list[UUID]] - - @classmethod - def resolve_reference(cls, id: UUID) -> Pet: - return Pet(id=id, toy_ids=find_toys()) - - @strawberry.field - def toys(self) -> list[Toy]: - [Toy(toy_id) for toy_id in self.toy_ids] - - @strawberry.type - class Toy: - id: strawberry.Private[UUID] - name: str - ``` - -## Schema Generation - -Schema generation can be performed using the `strawberry.printer.print_schema` method. -This will generate a string in the [GraphQL Schema Language](https://graphql.org/learn/schema/#type-language) format, which can be used to perform schema composition. - -!!! tip - - You will likely want to create a program entrypoint or CLI option which writes the schema to a file. - -!!! example "Schema Generation" - - ```python - from strawberry.federation import Schema - from strawberry.printer import print_schema - - SCHEMA = Schema(types=[], enable_federation_2=True) - - if __name__ == "__main__": - sdl = print_schema(SCHEMA) - print(sdl) - ``` diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index b018713..0000000 --- a/docs/index.md +++ /dev/null @@ -1,4 +0,0 @@ -# Graph - -The Graph, hosted at `graph.diamond.ac.uk`, presents a federated GraphQL API; -Allowing HTTP access to structured Diamond data from across the organisation. diff --git a/docs/references/terminology.md b/docs/references/terminology.md deleted file mode 100644 index 0d28432..0000000 --- a/docs/references/terminology.md +++ /dev/null @@ -1,15 +0,0 @@ -# Terminology - -### Schema - -A GraphQL schema is an artifact describing the API provided by a given GraphQL endpoint. -This is likely to contain a set of [Queries](https://spec.graphql.org/October2021/#sec-Query), [Mutations](https://spec.graphql.org/October2021/#sec-Mutation) and [Subscriptions](https://spec.graphql.org/October2021/#sec-Subscription), and a description of the [Objects](https://spec.graphql.org/October2021/#sec-Objects) which they return. - - -### Subgraph Schema -A Subgraph is the [Schema](#schema) of an individual service. These may be stitched together to form a [Supergraph](#supergraph). - -### Supergraph Schema - -A Supergraph is simply a GraphQL [Schema](#schema) which has been stitched together from various [Subgraphs](#subgraph). - diff --git a/docs/requirements.txt b/docs/requirements.txt deleted file mode 100644 index a0c9353..0000000 --- a/docs/requirements.txt +++ /dev/null @@ -1 +0,0 @@ -mkdocs-techdocs-diamond