Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[prototype] Compiled schema synchronization #113

Draft
wants to merge 3 commits into
base: 2.3
Choose a base branch
from

Conversation

bdunogier
Copy link
Member

@bdunogier bdunogier commented Nov 9, 2021

Eases the synchronization of graphql schema when using multiple servers.

Publishing a schema

One server will do the schema generation + compiling, and run a command (ibexa:graphql:publish-schema) to publish the schema. Publishing will a) push the compiled schema (%kernel.cache_dir%/overblog/graphql-bundle/__definitions__/*) to a SharedSchema, and b) set the published schema timestamp using a TimestampHandler.

In the current prototype, the TimestampHandler is based on Redis, and the SharedSchema on a locally mounted shared folder.

Pulling a published schema

Other servers, when a GraphQL query is executed (UpdateSchemaIfNeeded subscriber), will compare the timestamp to theirs (mtime of __classes.map). If a newer one is available, it will be pulled from the SharedSchema, and copied locally. It will get installed in a shutdown function to prevent op cache issues.

Since the graphql schema types are compiled into the container as services, types that were added to the published schema (new content types, etc) need to be registered on runtime. This is done by the Schema\Sync\AddTypesSolutions subscriber. It checks which of the type classes do not have a solution in the current schema, and adds them to it.

TODO

  • Add proper, dedicated exceptions to the SharedSchema implementation
  • Add a flysystem based implementation, that would include local, but also support any remote filesystem (need to update our version of flysystem to the new stable)
  • Add configuration for how many updates should be kept. When a new update is published, trim the old ones to respect that limit.

@bdunogier bdunogier force-pushed the compiled_schema_sync_2.3 branch 2 times, most recently from 8b7921a to abb8135 Compare November 24, 2021 17:28
@sonarcloud
Copy link

sonarcloud bot commented Nov 25, 2021

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 5 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant