|
| 1 | +# Code Generation Tool |
| 2 | + |
| 3 | + |
| 4 | + |
| 5 | +[](https://gitter.im/cloudlibz/cloudlibz) |
| 6 | +[](https://medium.com/leopards-lab) |
| 7 | +[](https://groups.google.com/g/score-community) |
| 8 | +[](https://github.com/leopardslab/nodecloud/issues) |
| 9 | + |
| 10 | +## Code Generation in NodeCloud |
| 11 | + |
| 12 | +This is where new source code is generated by assembling bits and pieces. The aim of this generator is to fill the JavaScript clases in NodeCloud plugins. This code generation process is based on TypeScript compiler API. This procress can be mainly divided into three main parts, |
| 13 | + |
| 14 | +1. Parsing the type definition files of cloud SDKs |
| 15 | +2. Traversing through the **Abstract Syntax Tree** of the source code and collecting required data |
| 16 | +3. Transforming a dummy **Abstract Syntax Tree** with the collected data to generate a new source code |
| 17 | + |
| 18 | +A high level idea of the code generator can be taken from the below rich picture. |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +The execution of the generator starts form the `main.ts` file, where the basic information regarding the service classes are taken from the `node-cloud.yml` file and depending on the cloud provider the basic information is directed to the respective generator(e.g. - Azure generator). |
| 23 | + |
| 24 | +## Structure of `node-cloud.yml` file |
| 25 | + |
| 26 | +* AWS |
| 27 | + |
| 28 | +``` |
| 29 | +AWS: |
| 30 | + create: elasticbeanstalk.d.ts createApplication |
| 31 | +``` |
| 32 | + |
| 33 | +<p align="center"> |
| 34 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/aws.JPG" /> |
| 35 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/aws_diagram.png" /> |
| 36 | +</p> |
| 37 | + |
| 38 | +* Azure |
| 39 | + |
| 40 | +``` |
| 41 | +Azure: |
| 42 | + create: arm-containerservice managedClusters.d.ts createOrUpdate |
| 43 | +``` |
| 44 | + |
| 45 | +<p align="center"> |
| 46 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/azure.jpeg" /> |
| 47 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/azure_diagram.jpeg" /> |
| 48 | +</p> |
| 49 | + |
| 50 | +* Google Cloud (client based) |
| 51 | + |
| 52 | +``` |
| 53 | +GCP: |
| 54 | + create: container v1 cluster_manager_client.d.ts createCluster |
| 55 | +``` |
| 56 | + |
| 57 | +``` |
| 58 | + GCP: |
| 59 | + getMetricData: monitoring v3 metric_service_client.d.ts getMetricDescriptor |
| 60 | + projectPath: monitoring v3 alert_policy_service_client.d.ts projectPath |
| 61 | +``` |
| 62 | + |
| 63 | +`projectPath` is not an API request. Generator is capable of creating functions which gives relevant objects as well. |
| 64 | + |
| 65 | +<p align="center"> |
| 66 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/gcp_client_based.jpeg" /> |
| 67 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/gcp_client_based_diagram.jpeg" /> |
| 68 | +</p> |
| 69 | + |
| 70 | +* Google Cloud (class based) |
| 71 | + |
| 72 | +``` |
| 73 | +GCP: |
| 74 | + mainClass: DNS |
| 75 | + createZone: dns zone.d.ts create |
| 76 | +``` |
| 77 | + |
| 78 | +<p align="center"> |
| 79 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/gcp_class_based.jpeg" /> |
| 80 | + <img src="https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/gcp_class_based_diagram.jpeg" /> |
| 81 | +</p> |
| 82 | + |
| 83 | +For the class-based SDKs there is a minor change in the `node-cloud.yml` to record the main class of an SDK. For the above scenario, it’s the DNS class. |
| 84 | + |
| 85 | +## Code parsers |
| 86 | + |
| 87 | +This is the simplest part of the code generation tool. The SDK files are read from the relevant SDKs as specified in the `node-cloud.yml` file. Afterwards, it is converted to an **Abstract Syntax Tree**. Finally, the class declaration Node of that **Abstract Syntax Tree** is returned. This retured Node is another **Abstract Syntax Tree** since a class declaration itself is another **Abstract Syntax Tree**. |
| 88 | + |
| 89 | +## Data extraction functions |
| 90 | + |
| 91 | +These functions are located in the generators of the each cloud providers. Each data extration function has a unique logic depending on the **Abstract Syntax Tree** of a SDK class. The goal here is to extract all the data required to generate the new JavaScript class. At the end it is retured as `classData`. The data extration function collects imports, clients, method parameters, types of parameters, method return types and package names. Additionally, class relationships are identified in the Google Cloud data extraction function for the Google Cloud class based transformer. |
| 92 | + |
| 93 | +## Transformers |
| 94 | + |
| 95 | +This is the most important part of the code generator tool. Currently, there are four transformers. Two transformers for Google Cloud, and one each for AWS and Azure. All of the transformers runs three main transformations. |
| 96 | + |
| 97 | +* `addFunctions`: In this transformation the basic structure of the code is created. Method Nodes are created to the number of functions in the `classData` object. If there are imports related to the class those statments are also added to the dummy **Abstract Syntax Tree**. |
| 98 | + |
| 99 | +* `addIdentifiers`: In this transformation all the Identifier nodes are updated. After this transformation the code is logically compelete. All the neccessary code parts are added and finalized such as parameter names, parameter types, client names, class name, package names, SDK function names etc. |
| 100 | + |
| 101 | +* `addComments`: This transformation aims to auto-generate the API documentation. All the comments are added to the structure required by `JSDoc`. The `@category` is used to categorize the generated classes depending on the cloud provider. This tag is from the `better-docs` template used with `JSDoc`. |
0 commit comments