JavaScript SDK

[johanstokking]

Summary: Since we would need abstractions on the stack API for the Console anyway, we decided to start building the JavaScript SDK alongside developing the Console. Here, it is planned to combine usage for the browser and Node.JS in a single SDK. The usage of the HTTP Bridge or gRPC directly can then be chosen as a config during instantiation of the SDK API object, depending on the capabilities of the given environment. The SDK will implement a stack API abstraction that provides the same normalized interface for both configurations. For HTTP, a mapping from rpc name to HTTP request is generated by the build process which is used to generate function definitions. For gRPC the generated JS stubs are used. The user will be able to use either the higher-level SDK API which provides simplified access to entities (like ttn.Applications.getById(id)) or call the underlying rpcs directly, resolved to HTTP or gRPC by the SDK. Following our mono-repo idea, the SDK will be part of this repo and published isolated via npm, using the old (to be updated) SDK repo for issues.

What is already there? What do you see now?

• Groundwork
• (Rough) Draft of SDKs API / Architecture
• Generating HTTP API interface from a protobuf generated JSON mapping

What is missing? What do you want to see? Note: this is still incomplete / wip

• [ ] Connecting to the stack API
  • [ ] Providing gRPC connection type
  • [x] Providing HTTP connection type
  • [ ] Normalized API that resolves to either connection type
• [x] Marshalling API specific things like field/update_masks
• [ ] Handling authentication
  • [x] Using an access token
  • [ ] Using API Keys
• [x] Abstraction for handling Applications
  • [x] CRUD
  • [x] Handling collaborators
  • [x] Handling API Keys
• [ ] Abstraction for handling Devices (via Application interface)
  • [x] CRUD (See #131)
  • [x] Handling collaborators
  • [x] Streaming data
  • [ ] Handling downlink/uplink queues
• [x] Abstraction for handling Gateways
  • [x] CRUD
  • [ ] Streaming data
  • [ ] Handling API Keys
• [x] General Event Stream API
• [ ] CI
  • [ ] Making sure API changes result in rebuild and republish of SDK
  • [ ] Testing SDKs conformity with API
  • [ ] Switch from preliminary API mapping at runtime to generated JS files
• [ ] npm publishing workflow
  • [ ] Provide repository for issues by the community
  • [ ] Add npm publish as part of CI
  • [ ] Synchronize versioning with stack

What can you do yourself and what do you need help with? After a initial PR for this by @kschiffer , we can see how work here can be split between @bafonins and @kschiffer . I think it's best to add functionality here as we need it in the console.

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/1087 by @kschiffer

[DomVinyard]

Heya, really interested in this, do you have a rough idea when this will be available, is there anything I can do to help :)

[bafonins]

hey @DomVinyard , thanks for interest. As you can see there are still quite some todos left for the sdk to be published to the npm registry. Progress on the javascript sdk goes along with the development of the v3 console. Fell free to join conversations in any PR's/issues related to the sdk, as well as checking existing API's (there currently support for managing applications).

[bafonins]

Consider refactoring the js sdk mage targets, see https://github.com/TheThingsNetwork/lorawan-stack/pull/1202#discussion_r315631148

[kschiffer]

Closing due to the SDK development being continuous. We should follow up with actionable issues derived from the OP rather.