JS-SDKGen — An automation library to generate Javascript SDK without any extra code
It was always a dream to sit back and watch my computer doing all the coding for me. It feels fascinating but the reality is a reality, it takes time to reach there. We all are in the era of automation. Most of the manual tasks in the manufacturing industry are being automated day by day and thus in computer technology too.
At Vitwit, we are developing various types of applications from half a decade now. Our regular days are filled with coding, debugging, building and deploying. We incorporated a lot of advanced tools to automate our works in monitoring, integration, and deployment. But it is always a task to sit and code extensively for any new application. Be it from definitions, APIs, SDKs, to test-scripts & monitoring, there’s a lot of code involved and a lot of manual effort indeed. Generally we, the developers are not bored with coding, I think that’s the reason, we don’t try to automate it. We follow devsecops culture here at Vitwit, thus we got some time and motivation to automate a few of our coding efforts. We felt bored with writing repetitive code. As being bored out of your mind makes you more creative, we found a few ways to automate our regular coding tasks. Great! Thanks to swagger’s codegen for making it easy for us in our first attempt i.e, JS-SDKGen (Javascript SDK Code Generator).
Why SDKs?
It is a known fact that SDK based integrations are more developer-friendly than APIs. It saves a lot of time for frontend devs to integrate and gives the freedom for API devs to modify the APIs as needed and release without affecting the integration (Unless there’s a new API or schema change). For example, if you are refactoring code and changing a few API URLs, instead of sitting on changing the integration, you can just modify your SDK and deploy. Integration works just fine. Though it has many advantages, API developers generally don’t choose developing SDKs along with APIs. It is double work for them to do so. Generally they need to write APIs & its documentation and they get to code SDK and usage guide. Its a fact, it was the same case with us too. We skipped writing SDKs for a few of our projects for the same reason. But soon, we understood the side effects with it and thus we made our first tool from VAutomate (Vitwit Automation Lab), called JS-SDKGen to generate the SDKs (Javascript) automatically. The brain behind this cool stuff is Mr. Yash
Our SDKGen generates the SDK by taking the API doc definitions from swagger/apidocjs json files. It considers the API definitions and generates functions for each API, which can be used for integrations. Not just that, it also generates the documentation needed to help frontend devs to use these SDK functions, thus reduces the work for API developers.
Installation
JS-SDKGen is an opensource solution and it is available on npm packages. You can install it by running the following command:
npm install -g @vitwit/js-sdkgenYou require Node.js installed in your system to use this and that’s it.
How to use JS-SDKGen?
Usage is simplified, it just requires few cli parameters and it will take care of everything else needed. The following command will generate your SDK.
js-sdkgen --json-file=swagger.json --name=SampleSDK --version=1.0.0 --base-url=https://vitwit.com/api --required-headers accountId --optional-headers accessTokenBelow are parameter available for node cli while generating SDK.
Any other parameters passed will be added to default headers for every API request.
Handling API specific Headers
This is a tricky part of the SDK generation. As we are automating the SDK generation, we need to understand, what are all the headers we need for our APIs. For example, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY are the required configuration credentials to use AWS SDKs. In the same way, if your SDK needs any credentials that need to be sent for every API request, you need to mention them as mandatory headers in headers configuration.
Optional Headers, as the name suggests, they are optional or required only for certain APIs. SDK will send those headers only after they are set. For example, if API requires, Authorization token for some APIs and not for all other APIs, it can be set as an optional header. There are two functions to set & clear these Optional Headers. Optional headers are useful when we need to deal with login/logout kind of scenarios. Few methods from SDK’s can be used optionally and when a user logged into the system, SDK should send authorization tokens from then. For this kind of cases, you can make use of OptionalHeaders and set & clear functions.
//to set the headers
mySDK.setHeader("OptionalHeader1", "OptionalHeaderValue");//to clear the headers
mySDK.clearHeader("OptionalHeader1");//to check if the header is present or not
mySDK.getHeader("Header1");
Here is an example:
//To set header parameters, ex: Authorization with Bearer token
mySDK.setHeader("Authorization", "Bearer <yourtokenhere>");//override existing config, i.e., baseUrl
mySDK.setBaseUrl("https://api.vitwit.com/v2");// you can also get any header value by calling getHeader
mySDK.getHeader("Authorization");
What’s so cool about this?
You don’t have to deal with calling API’s, managing API constants, handling errors, headers, params, query params, etc. On top of that, if API changes its data structure of response or routes, they can provide an object transformOperations with key as operationName functions which will take current data structure and provide the previous version for one who opts to use an old version.
For more information on how to use this tool, checkout our github: https://github.com/vitwit/JS-SDKGen
or npm package
https://www.npmjs.com/package/@vitwit/js-sdkgen
Conclusion
Automation is the Key activity at Vitwit and most of our stuff we are planning to opensource. We welcome contributions from the opensource community. If you have any suggestions/questions related to this project, you can reach out us on our Github account (https://github.com/vitwit/JS-SDKGen) or you can write at opensource@vitwit.com
Hope, you enjoyed reading the stuff. Happy coding!
