Run Capability
This guide describes how a capability can be used in any production Node.js application.
Prerequisites
- Existing Node.js project set up
- Existing profile
- Existing provider definition
- Existing map between the profile & the provider
Configure provider authentication
Optional
If the Provider JSON doesn't define any security schemes, or the map doesn't use security
, you can skip this step.
If you've created a completely new Provider JSON definition in your project, it will not have its security schemes configured in the local superface/super.json
configuration file.
Provider's security schemes must be configured in super.json
since OneSDK will search for it when authenticating the requests during use case perform.
The specific provider section will look like the following example:
{
"profiles": {
// ...
},
"providers": {
"<provider-name>": {
"security": []
}
}
}
Search in top-level providers
object for the actual provider you want to configure.
Configure using CLI
The easiest way to bootstrap the provider's security configuration is using Superface CLI.
superface configure <provider-name> -p <profile-name> --localProvider <path-to.provider.json> --localMap <path-to-provider-map.suma> -f
Replace the <profile-name>
, <path-to.provider.json>
, <provider-name->
, and <path-to-provider-map.suma>
in the command with the actual values.
Running the above command automatically creates security schemes configuration in super.json
based on Provider definition. It also prepares expected environment variables (if any are required) inside a .env
file.
Advanced users can configure the security manually instead.
Configure security in super.json
manually
If you configured security using CLI, you can skip this.
Configuring security manually
You'll need to provide a configuration based on the security scheme type. Currently the following schemes can be used:
Reading environment variables in super.json
You can be prepend any value assigned in super.json
with a dollar sign ($
) to reference an environment variable.
{
// ...
"token": "$PROVIDER_API_TOKEN"
// ...
}
When evaluating the above configuration, OneSDK will look for PROVIDER_API_TOKEN
value in environment variables.
Configure Basic Auth scheme
Use the following config and reference an existing security scheme from the Provider's JSON definition by an identifier.
{
"profiles": {
// ...
},
"providers": {
"<provider-name>": {
"security": [
{
"id": "<scheme-id>",
"username": "$PROVIDER_USERNAME", // will read `PROVIDER_USERNAME` from environment
"password": "$PROVIDER_PASSWORD" // will read `PROVIDER_PASSWORD` from environment
}
]
}
}
}
Replace <scheme-id>
with the actual security scheme ID defined in the Provider JSON document. You can use your own values for username
& password
. However it's a common practice to supply these values via environment variables.
Configure Bearer Token scheme
Use the following config and reference an existing security scheme from the Provider's JSON definition by an identifier.
{
"profiles": {
// ...
},
"providers": {
"<provider-name>": {
"security": [
{
"id": "<scheme-id>",
"token": "$PROVIDER_API_TOKEN" // will read `PROVIDER_API_TOKEN` from environment
}
]
}
}
}
Replace <scheme-id>
with the actual security scheme ID defined in the provider JSON document. You can use your own value for token
. However it's a common practice to supply these via environment variables.
Configure API key in headers or query
Use the following config and reference an existing security scheme from the Provider's JSON definition by an identifier.
{
"profiles": {
// ...
},
"providers": {
"<provider-name>": {
"security": [
{
"id": "<scheme-id>",
"apikey": "$PROVIDER_API_KEY" // will read `PROVIDER_API_KEY` from environment
}
]
}
}
}
Replace <scheme-id>
with the actual security scheme ID defined in the provider JSON document. You can use your own value for apikey
. However it's a common practice to supply these via environment variables.
Set environment variables
For apps running the capabilities that require authentication, you'll typically want to supply the providers' API keys via environment variables (see configuration above).
If .env
file exists and you used the CLI, the required environment variables will be present in the file. Fill in the providers' API keys. Then install the dotenv
package to load the .env
file.
If .env
file doesn't exist, you can find the expected environment variables in /superface/super.json
. Any value that starts with a dollar sign ($
) is a reference to an environment variable.
Write Node.js app
Use the OneSDK to load and perform the use case:
// If you're using .env file, you should also install and init `dotenv` package
require('dotenv').config();
const { SuperfaceClient } = require('@superfaceai/one-sdk');
const sdk = new SuperfaceClient();
async function main() {
const profile = await sdk.getProfile('scope/profile-name');
const result = await profile
.getUseCase('UseCaseName')
.perform(/* Input object as defined in the profile */);
console.info('Hooray!', result.unwrap());
}
main();
Replace scope/profile-name
, UseCaseName
and inputs for .perform
method with the use case details you actually want to use.
info
For details on SuperfaceClient API, please consult OneSDK reference.
Run the app
Now run the application to perform the use case and check the results:
node app.js
Offline Use
To use capability without the use of Superface remote registry. You have to import capabilities into project and ensure super.json
has valid paths to your capabilities.
Observe and debug API calls
OneSDK uses the debug package which is useful for observing the behavior of the SDK and debugging. To use it, set environment variable to DEBUG="superface*"
before running the application:
DEBUG="superface*" node app.js
To observe just the API calls, you can use superface:http
debug context:
DEBUG="superface:http*" node app.js
Sensitive Output
Using the superface:http*
context will output full HTTP requests and responses including API keys and other sensitive data.