Rebill SDK :rocket:

As we previously mentioned, this repository contains all the logic attributed to the SDK. Its main function is the initialization of the new SDK instance and sending messages to the iframe.

Its action is fundamental since it allows the client to interact with the iframe without necessarily manipulating it. The communication follows this flow: client → sdk → iframe (we will detail the responsibilities of this iframe in rebill-elements-v3).

The V3 project is made with Typescript and built with Webpack. The resulting minified JS file is hosted in the AWS bucket named rebill-sdk-demo-[env], with env taking the value associated with its environment (stg or prod).

In the same repository, the infrastructure necessary for the npm package named rebill is hosted, which gathers and makes all this logic available. The package is deployed on npm through an action configured in the project.

Project Structure

Let's review directory by directory.

Outside of any folder in the project root, we have all the configuration files:

• package.json
• tsconfig.json
• webpack.prod.js: responsible for building the code for deployment on AWS
• webpack.config.js: responsible for building the code for the NPM package

Within /src live both the SDK V2 project, named as panthon-sdk, and also the V3 project simply called sdk.

We will not discuss the internal structure of the panthon-sdk directory since we no longer maintain this version, but we will detail the sdk folder associated with V3:

• index.ts: is the SDK's entry point, and all the methods later made available to the client are defined in it.
• constants.js: simply constants.
• services: services consumed in the application.
• schemas: type and interface definitions.

In the shared directory, there are common declarations for both SDK V2 and V3.

In npm-package, you'll find the structure associated with the NPM package. The rebill directory has the code that is later published as a downloadable package from NPM. The package allows the user to interact with all the functionality provided by the SDK, without the need to manually add a script tag to their HTML, but simply by downloading the library with their package manager. The test directory serves only to locally test the package before publishing it.

In dist is the js minified file that is later uploaded to the S3 bucket and is made available to clients as an option to consume the SDK.

In demo, examples of the SDK use cases are hosted for local testing.

Usage

To use the project locally, simply add a script tag to the HTML in which you want to work and start using the methods exposed in the index.ts file of the sdk directory, as shown in the demos hosted in the demo directory.

To see the changes made in the code reflected, you need to rebuild the entire project with the build command, described in the package.json. After a build, the /dist/v3/rebill.min.js and /npm-package/rebill/ files are created.

env file

To use the project locally, you need the following environment variable configuration file:

LOCAL_ELEMENT=http://localhost:3006/v3/
API_BASE=http://localhost:8000
SDK_REBILL_GATEWAY=https://secure.rebill.dev

With LOCAL_ELEMENT being the variable associated with the iframe URL. If running locally, in conjunction with Rebill Elements, the value set in the previous code snippet should be used. API_BASE refers to the URL associated with the backend where requests will be made, and lastly, SDK_REBILL_GATEWAY is the parameter associated with the anti-fraud engine that runs with each transaction.

Build and Workflows

The project has two workflows that run upon making a push to the main branch:

• deployment.yaml: responsible for deploying to the S3 bucket. Both for stg and for