Language bindings
A binding runs Nexyron inside your own process. There is no server to deploy, no port to secure and no network hop between your application and its data: you open a database, run queries, and close it.
This suits applications that own their data and want analytical questions answered locally. Where several applications or people share one dataset, run Nexyron as a server instead and connect over HTTP.
What every binding gives you
The same core, so the choice of language changes the syntax and nothing else:
- Open or create a database, and close it cleanly.
- Run Cypher and read back typed rows.
- Parameters, so values never have to be pasted into query text.
- Transactions, where a group of changes commits or fails together.
- The same graph algorithms, history and analytical procedures available everywhere else.
Language-specific guides:
Identifiers, and one thing to watch
Every subject and relationship has an identifier. Return it as a string, using
the element_id() function, whenever it will cross into JavaScript.
MATCH (c:Customer) RETURN element_id(c) AS id, c.name AS name
JavaScript numbers cannot represent large integers exactly, so an identifier that arrives as a number can be silently altered in transit and will then fail to match anything. It is the single most common integration bug, it is invisible until a lookup mysteriously returns nothing, and returning strings avoids it entirely. Languages with 64-bit integers are unaffected, but returning strings everywhere keeps one habit instead of two.
Choosing between embedded and server
Reach for embedded when the data belongs to one application, when you want no network in the path, or when you are shipping an application that must work offline.
Reach for the server when several clients share one dataset, when you want the browser interface alongside the API, or when the data outlives any single application.
Both run the same engine and the same query language, so moving between them is a change of connection, not a rewrite.