Skip to content

Commit a0cf6bc

Browse files
committed
Creating ReadMe for Code generator
1 parent aa83615 commit a0cf6bc

File tree

10 files changed

+101
-0
lines changed

10 files changed

+101
-0
lines changed
42.9 KB
Loading
35.6 KB
Loading
37.7 KB
Loading
33.3 KB
Loading

assets/generator/rich_picture.png

1.27 MB
Loading
23.5 KB
Loading
20.3 KB
Loading
22.6 KB
Loading
19.9 KB
Loading

generator/README.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# Code Generation Tool
2+
3+
![ts](https://flat.badgen.net/badge/Built%20With/TypeScript/blue)
4+
5+
[![Gitter](https://img.shields.io/badge/chat-on%20gitter-brightgreen)](https://gitter.im/cloudlibz/cloudlibz)
6+
[![Read on : Medium](https://img.shields.io/badge/Read%20on-Medium-black.svg)](https://medium.com/leopards-lab)
7+
[![Mailing list : Scorelab](https://img.shields.io/badge/Mailing%20list-Scorelab-blue.svg)](https://groups.google.com/g/score-community)
8+
[![contributions welcome](https://img.shields.io/badge/contributions-welcome-ff69b4.svg?style=flat)](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+
![Rich picture](https://raw.githubusercontent.com/rajitha1998/waterme-Project/master/code_generation_tool.png)
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

Comments
 (0)