The Amplify CLI provides the command amplify plugin init (with alias amplify plugin new) for the development of plugins. This command first collects requirements, and then creates the skeleton of the plugin package for you to start the development. The newly created plugin is added to your local Amplify CLI plugin platform, so you can conveniently test its functionalities while it is being developed. It can be easily removed from the local plugin platform with the amplify plugin remove command, and added back with the amplify plugin add command.
You will be prompted to enter the plugin name, then select the plugin type, and event subscriptions. The CLI will then create a plugin package for you and add it to the local Amplify CLI plugin platform.
Step 3: Test your pluginThe newly created plugin package is already added to the local Amplify CLI, so you can start testing it immediately. Let's say you have chosen to use the default plugin name: my-amplify-plugin
$ amplify my-amplify-plugin help
help command to be implemented.
You will see that the default help message is printed out. At this point, there are only two sub commands in the plugin package, help and version, with dummy implementations. If you try to execute any other command, it will trigger the Amplify CLI plugin platform to perform a fresh scan, and then after it failed to find the command, it will print out the default help message.
From here, you can start to develop the plugin package. See below for the detailed explanation of the package structure.
Step 4: Publish to npmAfter the completion of one development cycle and you are ready to release your plugin to the public, you can publish it to the npm: https://docs.npmjs.com/getting-started/publishing-npm-packages
Step 5: Install and UseOnce your plugin is published to the npm, other developers can install and use it
Plugin Package StructureHere's the plugin package directory structure
amplify-plugin.jsonThe amplify-plugin.json file is the plugin's manifest file, it specifies the plugin's name, type, commands and event handlers. The Amplify CLI uses it to verify and add the plugin package into its plugin platform.
Here's the contents of the file when it's first generated by the amplify plugin init command for a util plugin.
The "main" file specified in the package.json is the Amplify CLI's entry to invoke the plugin's functionalities specified in the manifest file amplify-plugin.json.
Here's the contents of the file when it's first generated by the amplify plugin init command for a util plugin.
The commands folder contains files that implement the commands specified in the manifest file amplify-plugin.json.
The event-handlers folder contains files that implement the eventHandlers specified in the manifest file amplify-plugin.json.
This section outlines the process of writing custom GraphQL transformers. The @aws-amplify/graphql-transformer-core package serves as a lightweight framework that takes as input a GraphQL SDL document and a list of GraphQL Transformers and returns a set of deployment resources that fully implements the data model defined by the input schema. A GraphQL Transformer is a class that defines a directive and a set of functions that manipulate a context and are called whenever that directive is found in an input schema.
For example, the AWS Amplify CLI calls the GraphQL Transform like this:
As shown above the GraphQLTransform class takes a list of transformers and later is able to transform GraphQL SDL documents into deployment resources, this includes the transformed GraphQL schema, CloudFormation templates, AppSync service resolvers, etc.
At a high level the GraphQLTransform takes the input SDL, parses it, and validates the schema is complete and satisfies the directive definitions. It then iterates through the list of transformers passed to the transform when it was created.
In order to support inter communication/dependency between these classes of transformers, the transformation will be done in phases. The table below shows the lifecycle methods that a transformer plugin can implement to handle different phases in the execution of the transformer:
Lifecycle method Description before initialization of the transformer GraphQL visitor pattern functions object for each type that has the directive defined by the transformer interface for each interface that has the directive defined by the transformer field for each field that has the directive defined by the transformer argument for each argument that has the directive defined by the transformer union for each union that has the directive defined by the transformer enum for each enum that has the directive defined by the transformer enumValue for each enumValue that has the directive defined by the transformer scalar for each scalar that has the directive defined by the transformer input for each input that has the directive defined by the transformer inputValue for each inputValue that has the directive defined by the transformer prepare transformer register themselves in theTransformerContext (as data provider or data enhancer) validate transformer validates the directive arguments transformSchema transformer updates/augments the output schema generateResolvers transformer generates resources such as resolvers, IAM policies, Tables, etc. after cleanup, this lifecycle method is invoked in reverse order for the registered transformers
Here is pseudo code for how const { rootStack, stacks, schema } = graphQLTransform.transform(schema); works.
The transformer context serves like an accumulator that is manipulated by transformers. See the code to see what methods are available to you.
Adding Custom GraphQL Transformers to the ProjectFor now, the transformer only support CloudFormation and uses AWS CDK to create CloudFormation resources in code.
To add a custom GraphQL transformer to the list of transformers, they need to be registered within the project. This registration can be done by adding an entry to transform.conf.json file which can be found in the amplify/backend/api/<api-name> folder. A transformer can be registered by adding a file URI to the JavaScript file that implements the transformer or by specifying the npm package name. The transformer modules will be dynamically imported during the transform process.
transform.conf.json file Example
As an example let's walk through how we implemented the @model transformer. The first thing to do is to define a directive for your transformer.
Note: Some parts of the code will not be shown for brevity.
Our @model directive can be applied to OBJECT type definitions and automatically adds CRUD functionality, timestamp fields to an API. For example, we might write:
The next step after defining the directive is to implement the transformer's business logic. The @aws-amplify/graphql-transformer-core package makes this a little easier by exporting a common class through which we may define transformers. Users extend the TransformerPluginBase class and implement the required functions.
Note: In this example
@modelextended from a higher level class,TransformerModelBase.
Since your directiveDefinition only specifies OBJECT in its on condition, we have to implement the object method and some other lifecycle methods like validate, prepare and transformSchema to have a fully functioning transformer. You may implement before and after methods which will be called once at the beginning and end respectively of the transformation process.
The following snippet shows the prepare method implementation which takes all the type from the GraphQL schema and registers the transformer as a data source provider. Data source providers are used by transformers that are creating persistent resources like DynamoDB tables in this case. prepare is the place to register data enhancers as well. Data enhancers are used by transformers that enriching existing types or operations by adding or modifying fields, arguments, etc.
For the full source code of the @model transformer, go here.
Add the VSCode extension to get code snippets and automatic code completion for Amplify APIs.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4