This repository contains the TypeScript library for Nokia's Network as Code platform, allowing Python programs to easily call network APIs to query information or to manage mobile network elements.
Network as Code is a network API aggregator platform developed by Nokia to expose network capabilities of mobile networks to applications. It provides numerous capabilities ranging from quality-of-service to network-based location services and analytics.
You can find more information over at the Nokia home page or by going directly to the developer portal: https://developer.networkascode.nokia.io/
You can find a full Getting Started guide on the developer portal: https://developer.networkascode.nokia.io/docs/getting-started
Full documentation is available on the developer portal: https://developer.networkascode.nokia.io/docs
We also provide some basic usage examples in the examples directory.
The Network as Code TypeScript SDK is open-source software available under the Apache 2.0 license.
npm install- install project dependenciesnpm build- compile the project usingtscnpm test- run unit tests against mocksnpm run integration- run integration tests against development APIs
This project is structured into models, api and namespaces
modules. The models and namespaces modules represent the public
API of the SDK and provide abstractions that allow data to be queried
and modified on the Network as Code platform. The api module implements
the communication layer that will actually talk to the NaC web APIs and
handle transmission and receipt of data to and from the platform.
The basic design principle is that functionality should be discoverable
and logically organized. To achieve that, most actions are carried out
through the NetworkAsCodeClient object, which provides access to the
namespaces in the namespaces module. These namespaces typically provide
ways to query and create different types of data objects in the NaC
platform. The data objects themselves have representations in the models
module, and are enriched with methods that operate on the individual
data object.
New features typically require modifications to at least the models
and api modules. New namespaces are introduced as required, typically
when a new API product is launched. However, the namespaces are intended
to be an organizational tool and as such should be used whenever a concept
falls into a new kind of category and to avoid clutter.
This project is developed using principles from Test-Driven Development. This means that for new bugs fixed and features implemented, there should be matching test cases written.
Tests split into tests which are test cases against mocks and intended
to work offline and without need to actually connect to an external system.
We also have integration-tests which use a development version of the APIs
to track compatibility. Both test suites are run in CI/CD and failures are
considered blocking.
Test cases should be added to as part of regular development activity and old test cases should be kept up-to-date.
New features and changes to old ones should also be documented as soon
as possible. This means that developers ought to be in contact with the
technical writers whenever a change is introduced. It is also recommended
to add an example or update old examples in the examples folder to help
communicate functionality and changes to the documentation writers. If
no technical writer is present then the responsibility of writing documentation
falls on the developers. Developers also need to be able to provide input
to the technical writers to ensure accurate and high-quality documentation.
The branching strategy is based on a split between new releases and bug fixes. The main branch should contain functionality that either has been released or will be released shortly + bug fixes. For unreleased features a specific release branch for that release will be used and merged to main on release. This way the main branch can be kept in sync between GitHub and internal GitLab without worrying about unreleased content.
The overall workflow for a release content is like so:
- When new release is started, a release-YY.M branch is created from main
- All planned features will be created on feature branches and MR'd towards the release branch
- Bug fixes affecting existing releases will be MR'd towards main branch and release branch rebased on main
- Bug fix releases can be tagged from main, these bug fixes should also be pushed to GitHub
- Once release content is ready, the release branch is MR'd to main
- Main should be synchronized with GitHub
- New release is tagged from main
Bug fixes and new features originating from GitHub should follow the same process, except the GitHub release branch will not contain internal, unfinished code. This branch should be created when a PR is first created for the GitHub repository and will be merged with main after step 6. Bug fixes can be merged directly to main and synchronized with internal GitLab.