NLX is an open source peer-to-peer system facilitating federated authentication, secure connecting and protocolling in a large-scale, dynamic API ecosystem with many organizations.
NLX is built as a core component of the Common Ground vision, which aims to convert or replace the current monolithic information systems of Dutch municipalities (and wider government) with a state of the art, API-first software landscape, fulfilling societal demand for automation, transparency and privacy.
Important business benefits of NLX are:
- Lower integration costs because of standardised API integration layer
- Better data quality because data is used at the data source
- Better AVG compliance because end users get insight into data usage
- Better logging and auditing of data usage
- More agile software systems because NLX facilitates component based software systems
To reduce integration costs and simplify building component based software systems, everyone should be (technically) able to use API's in other organizations as easy as in their own, while core data objects should only be manipulated by the one administratively responsible and used by all others. An additional advantage is that public data can easily be made available to everyone. NLX makes it possible to easily and securely connect to any API in the ecosystem.
High level business overview
Starting with NLX implies starting with API’s. More specific it's starting with generic API’s instead of one-off integration solutions. NLX is useful for both organizations that want to consume API's and organizations that want to provider API's to other consuming organizations.
NLX is developed mainly by VNG Realisatie, but anyone can contribute on Gitlab. To start using NLX, it is not necessary to contribute to NLX development, since NLX can be installed 'as is'. A good way to start is by reading the documentation and having your system engineers or suppliers follow the Try NLX guide to learn the concepts of NLX and set up the first test implementation. Some knowledge of IT, the internet, API's and security is required. The NLX team is available through Gitlab for support to developers.
Setting up the first Outway for testing is done in a matter of a few hours, setting up an Inway requires having a basic API and a publicly resolvable URL. Configuring the inway is done in a few hours, setting up the API might take more time depending on your infrastructure. Launching a service on a public available network (the internet) requires more than just bringing the NLX and API software to production. A project should address all functional and non functional requirements and business context before launch.
Consuming API’s is easier than providing an API. A good place to start is to consume an already available API. Such as for example the BAG API of the Dutch Kadaster or the KVK API of the Dutch Chamber of Commerce.
Providing API’s trough NLX is quite straightforward when the API’s are already available. Suitable API’s to start with as a provider are two examples of API’s that Amsterdam has made available. Consider providing an API for monuments or garbage bin’s by reusing the already developed API specifications: Monumenten API or Afval API.
High level technical overview
Within the NLX integration landscape there are two main concepts: applications and services. Applications are only available within organizations and usually provide users a client interface to query and mutate data. Services provide API's to applications and are accessable within and across organizations.
NLX provides a developer friendly way to use standardised resources between organizations. It provides a gateway for querying services on the ecosystem as well as an gateway to offer services to the ecosystem. NLX provides support for HTTP/1.x services like REST/JSON and SOAP/XML. HTTP/2 support (gRPC) has been added.
NLX provides two different types of gateways: the inway and outway. Through an inway an organization can provide services to the NLX ecosystem and through an outway an organization can query services on the NLX ecosystem. The gateways are usually deployed centrally within the organization although it is possible for one organization to deploy multiple instances of inway and outway on different locations.
Here you can see a full request-response flow on NLX. An application performs a request on the outway within the same organization. The outway routes the request to the inway of the organization providing the service. The inway routes the request to the service. The service responds to the request and this response is routed through the NLX landscape, to the outway and arrives at the application.