[Proposal] Decoupling GraphQL API development from API design #4620
Labels
module/graphql
Issues related to Ballerina GraphQL module
Status/Active
Proposals that are under review
Team/PCM
Protocol connector packages related issues
Type/Proposal
Summary
When developing APIs there are two standard practises: code first and contract first. In the case of contract first you first design the GraphQL schema and then implement the agreed schema. This proposal is to improve Ballerina for contract first approach.
Goals
Motivation
As mentioned in the summary API development can be broken into two main practises: code first and contract first. In the case of contract first, the schema design is done first and then the implementation is done second. This allows the schema to have its own evolution life-cycle and code to have its own. During schema design domain expert may play a significant role whereas during implementation technology expert may play a significant role. The time taken to design a particular schema and the time taken to implement a designed schema could also vary. Therefore, it makes sense to provide a way to independently evolve each of these.
Description
At the moment, Ballerina has a visualiser which allows us to design the schema. However the problem with the current implementation is we generate a service skeleton. This binds the design and development together.
Instead of generating the service skeleton it is possible to generate service types. Following is an sample code.
This part of the code can be in a separate Ballerina package and can be released independently. Then the implementation code can add the dependency to the release package and continue implementing the schema.
In addition, the above code is enough to generate the GraphQL schema from the code. Effectively, this becomes an alternate syntax to define GraphQL schema.
However, the above to work, it is needed to introduce a new service type as
graphql:NestetedService
. Ballerina GraphQL module by default map service object types to GraphQL interfaces. Therefore, to distinguish GraphQL interfaces from GraphQL nested services, the proposed service type is needed.Please note that, it is not going to be a breaking change.
Dependencies
The text was updated successfully, but these errors were encountered: