Integrate Databases, Devices, and Software from Multiple Locations into Your Web Application

Why can nyssr.net integrate local services behind firewalls?

Access

nyssr.net is a network of interconnected Java nodes using TCP channels to facilitate message exchange. Messages are routed through these channels, avoiding the need to establish new connections dynamically.

A node started behind a firewall can easily connect to another node in the cloud. All connected nodes are visible to each other. All nodes are treated equally, regardless of where they are executed. This allows services to be offered or used by any node.

A local database can be easily accessed via a service on a local node. If this service provides an API for reading from or writing to the database, any other service – even on remote nodes – can use this service.

The same applies to using other local resources, such as hardware APIs or software APIs.

Protocol

nyssr.net does not use HTTPS internally but a bidirectional packet protocol. This protocol is optimized for speed and resource usage. Data is not transported using JSON or XML but is streamed instead. This saves bandwidth and CPU resources. It utilizes open connections between nodes, eliminating the need to negotiate connections for each request, making it significantly faster than HTTP.

As a result, we don’t need static IPs or high bandwidth to use local resources.

Service Resolution

Microservices in nyssr.net are automatically resolved. No configuration is required – no IP addresses, node addresses, or target addresses.

Security

Credentials for databases only need to be stored on the local node.

Internally, nyssr.net uses session management with users, roles, and permissions. Permissions can be created and assigned as needed. Thus, access to a table can be controlled with specific rights at the API level.

Customization

You can design services to ensure minimal resource usage. For example, it is advisable to avoid JPA, Hibernate, etc., for databases. Prepare the requested data before sending it, by:

• Sending only the data that is needed (SQL!)
• Filtering data at the source
• Preparing timestamps
• Buffering large result sets and adjusting the API (next chunk, please)

Avoid sending entire entities.

Result

You will be amazed at how many requests can be sent through a narrow connection.