✨ Cloud SDK

The Alternate Futures Cloud SDK provides an unified interface to help you quickly build applications that leverage our Alternate Futures Services.

It's distributed as an ESM module for Web browsers, or CJS module for NodeJs Server applications. The server version provides a wider range of features, as some features are dependent of Native NodeJs modules.

To learn more about it read our documentation available here.

Overview

• 🤖 Install
• 👷‍♀️Development
  • Code format
  • Changeset
• 🧸 Basic Usage
• 📖 Docs
• 🙏 Contributing
  • Branching strategy
  • Contributing
• ⏱️ Changelog

Requirements

• Nodejs as runtime
• NPM, Yarn to install the SDK, or PNPM for development
• Familiarity with Nodejs, Frontend/Client side development

Install

Install the package by executing:

npm i @alternatefutures/sdk

⚠️ If you're planning to contribute as a developer, you must install pnpm, otherwise most commands will fail.

For a quick start, learn the basic usage, or alternatively visit our documentation

Development

For developers looking to contribute to the @alternatefutures/sdk, clone the repository and follow the contribution guide.

Once cloned, you'll have to set up the local development environment, e.g. to have access to the source-code, iterate, run tests and much more.

For runtime we utilize Nodejs and PNPM as the package manager.

Create a new file named .env in the root directory of your project. This file will store environment variables needed for local development.

touch .env.production

Open the .env.production file in a text editor and add the following:

SDK__AUTH_APPS_URL="https://auth-apps.service.alternatefutures.ai"
SDK__IPFS__STORAGE_API_URL="https://storage-ipfs.service.alternatefutures.ai"
SDK__GRAPHQL_API_URL="https://graphql.service.alternatefutures.ai/graphql"
SDK__UPLOAD_PROXY_API_URL="https://uploads.service.alternatefutures.ai"

💡 The variables above point to our production environment, the same you interact with as an end-user.

Next, install the project dependencies:

pnpm i

Learn the Alternate Futures SDK basic usage here. For extended documentation visit our documentation site.

Code Format

Formatting and linting are facilitated by BiomeJS. Configuration details can be found in:

biome.json

To format source code and apply changes directly in the file:

pnpm format

For checking source code formatting only:

pnpm format:check

To lint and apply changes directly in the file:

pnpm lint

For lint checks only:

pnpm lint:check

To both format and lint source code (with writes):

pnpm format:unsafe

Changeset

Manage the versioning of changelog entries.

Declare an intent to release by executing the command and answering the wizard's questions:

pnpm changeset:add

Basic usage

The following provides a basic example of how to import the web browser or node SDK versions into your project and run a few simple commands.

For a complete description, read our documentation here.

Browser

The browser version is meant for applications that should run in a web browser and do not require NodeJs native modules.

Start by importing the web version from our SDK.

import { AlternateFuturesSdk } from '@alternatefutures/sdk/browser';
const sdk = new AlternateFuturesSdk({
  personalAccessToken: '<PERSONAL_ACCESS_TOKEN>',
});

Alternatively, omit the /browser path, as it'll default to the web version due to retroactive support. Although, it's recommended to specify the desired target for clarity.

import { AlternateFuturesSdk } from '@alternatefutures/sdk';

💡The <PERSONAL_ACCESS_TOKEN> can be obtained by utilizing the @alternatefutures/cli, learn more about it here.

NodeJs

For NodeJs projects import the distribution under the path @alternatefutures/sdk/node. This is a commonjs distribution (CJS), suitable for NodeJs environments. The Nodejs version has a wider feature support due to some features requiring features such as the file system, etc.

Use the following import statement:

import { AlternateFuturesSdk } from '@alternatefutures/sdk/node';

If you don't specify the /node path, it'll import the client version (web), that has a narrower feature set.

Here's an example where we import the AlternateFuturesSdk, the PersonalAccessTokenService and get the applications list.

import { AlternateFuturesSdk, PersonalAccessTokenService } from '@alternatefutures/sdk/node';

const personalAccessToken = '<PERSONAL_ACCESS_TOKEN>';
const projectId = '<ALTERNATEFUTURES_PROJECT_ID>';

const accessTokenService = new PersonalAccessTokenService({
    personalAccessToken,
    projectId,
});

const sdk = new AlternateFuturesSdk({
  accessTokenService,
});

(async () => {
  const res = await sdk.applications().list();
  console.log(res);
})();

Contributing

This section guides you through the process of contributing to our open-source project. From creating a feature branch to submitting a pull request, get started by:

1. Fork the project here
2. Create your feature branch using our branching strategy, e.g. git checkout -b feat/my-new-feature
3. Run the tests: pnpm test
4. Commit your changes by following our commit conventions, e.g. git commit -m 'chore: 🤖 my contribution description'
5. Push to the branch, e.g. git push origin feat/my-new-feature
6. Create new Pull Request following the corresponding template guidelines

Branching strategy

The develop branch serves as the main integration branch for features, enhancements, and fixes. It is always in a deployable state and represents the latest development version of the application.

Feature branches are created from the develop branch and are used to develop new features or enhancements. They should be named according to the type of work being done and the scope of the feature and in accordance with conventional commits here.

Conventional commits

We prefer to commit our work following Conventional Commits conventions. Conventional Commits are a simple way to write commit messages that both people and computers can understand. It help us keep track fo changes in a consistent manner, making it easier to see what was added, changed, or fixed in each commit or update.

The commit messages are formatted as [type]/[scope] The type is a short descriptor indicating the nature of the work (e.g., feat, fix, docs, style, refactor, test, chore). This follows the conventional commit types.

The scope is a more detailed description of the feature or fix. This could be the component or part of the codebase affected by the change.

Here's an example of different conventional commits messages that you should follow:

test: 💍 Adding missing tests
feat: 🎸 A new feature
fix: 🐛 A bug fix
chore: 🤖 Build process or auxiliary tool changes
docs: 📝 Documentation only changes
refactor: 💡 A code change that neither fixes a bug or adds a feature
style: 💄 Markup, white-space, formatting, missing semi-colons...