Gateway
- Goncalves, Felipe
The intl-whitelabel-app has two ways of communicating with the backend, through intl-whitelabel-graphql and intl-gateway-service. To know which of the applications the front is using, we can look at some flags that perform this control.
Document to complement the explanation:
https://rbictg.atlassian.net/wiki/spaces/CPT/pages/3900735663
We can look at which query is called in the desired flow. For example, the “GetRestaurant” restaurant flow, in the GraphQL query, uses the enable-gateway-restaurant flag to control whether it will use the gateway or not:
With the flag turned on it will flow to the gateway, this can be proven by looking at the Whitelabel call where the url has "gateway":
About intl-whitelabel-graphql in short, it uses Apollo Studio itself with the repository to make requests in the back-end, using it we don't need major changes, just run the command “yarn graphql:types” where it will generate the fields to also be used on the front-end. At the front, we run the command “yarn apollo:generate”.
About intl-gateway-service in short, it came to replace intl-whitelabel-graphql and Apollo Studio, it makes a link with all other back-end repositories, but the GraphQL schemas are controlled in each repository, so to avoid the problem of “breaking changes”, it needs to validate these schemas in some way, and it does this with Amazon's S3.
Document to complement the explanation:
https://rbictg.atlassian.net/wiki/spaces/CPT/pages/4043505669
More complex cases of adding a new field to an existing type in several repositories, for example, the OperatingHours type is used in 3 back-end repositories in the "fulfillments, delivery and store" gateway flow, these three repositories have their schemas with OperatingHour.
If you try to add only the pipe to the intl-fulfillment-service, it will perform a “graphql-schema-registry check” analysis, this is performed for different markets and brands, it is in this step that all GraphQL schemas in the Gateway flow will be validated. And in this example case, it will give some errors as shown in the print below.
In this error, it informs that the OperatingHours.satAdditionalTimeSlot field is not in the delivery subgraphs. This occurs because this field was not really added to the delivery schema, so we need to add it there first.
The correct thing to do at this point is to research the operatingHours type and discover all the schemas that it is present in.
After discovering this we have to add this field to one of the repositories, but as a security measure we did add the new field with an @inaccessible directive from Apollo details here, of according to the documentation we can add this directive in only one repository and this is sufficient to resolve these problems, as with this directive the field is ignored and will not cause integration problems, after add the new field to all schemas with the apollo inaccessible directive, we must remove them.
PS: This validation will be to do in every environment, so to remove this we need to wait until this be merged in PROD.
After remove and merge all PRs subgraphs will update the schemas in S3 and after this we can run the command “yarn apollo:generate” in the front-end and this will create the new fields.
Attention, after the merge it can take a few hours to update all the schemas in GraphQL on S3, and it will only generate the new fields in the front-end after the files are updated on S3, in my case it was released just a day later, I don't know if there is any job nightly that runs these updates.
Examples of PR can be seen in this Jira:
https://rbictg.atlassian.net/browse/IBFEC-1214
More details about this problem can also be seen in these slack threads:
https://rbidigital.slack.com/archives/C04CXB0EQ0N/p1700849600254709
https://rbidigital.slack.com/archives/C029ZDE2KKK/p1684347925108369
Problems
Problem: S3 File not update
Sometimes we can change a schema file and made a merge, but after the merge maybe can’t be published the new fields in the S3 Amazon. In the pipe show success:
But if you enter some graphql-schema-registry you to see that not changed in the schema:
And with this the file of S3 not update.
Solution:
You can rerun the steps of graphql-schema-registry, just go to the step and click in rerun:
This will create a new run in the pipe
when it finishes, you can check if changed the file and schema:
After this, you can check the S3 file changed.
PS: you need to rerun this for all markets and brands of pipe.
PS: Maybe when you remove the directive @innacessible the schema-registry don’t identify the changes, so you need to alter more things, for example, remove the @innaccessible in the top of file.