Modern database should natively support Transactionally-Reactive Programming
In order to simplify and speed up the development of data-intensive visual applications, Nezaboodka introduces the concept of transactionally-reactive programming.
In a typical application, data in an underlying database is continuously changed by users and other applications. Developers spend a lot of time and effort ensuring their applications consistently display updated data on user screens. Most of the efforts are spent on reactive programming in the UI and transactional processing in the database.
Reactive programming is a paradigm of automatic propagation of data changes to user screens or to other applications. It is achieved by automatic and seamless tracking of all dependencies between source and derivative data in an application. A good illustration of reactivity is an Excel spreadsheet: when a cell value changes, all dependent cells are automatically recomputed and refreshed on screen. Transactional processing is a well known principle of performing data operations in ACID-compliant (atomic, consistent, isolated, and durable) way from a client standpoint . Transactional reactivity is the synergy of both concepts meaning that all data displayed on user screens is immediately and consistently refreshed once a transaction in the underlying database has completed.
Implementing transactional reactivity is hard — you need to consistently propagate changes from a typical relational database to an object-oriented UI through object-relational mappings (ORMs), middleware layers, and reactive programming frameworks. This requires a lot of manual work, custom development and integrations, which developers repeat again and again in each and every application regardless of the technology stack: SQL, ORM, EF, Hibernate, NodeJS, Java, .NET, Ruby, WebSockets, SSE, JavaScript, Swift, and so on and so forth. To develop each layer, you need to involve several engineers with different areas of expertise, thus turning a simple data visualization task into an unpredictable planning and execution activity. Say “hello” to costs and “good bye” to time to market.
In our opinion, database should provide seamless transactional reactivity out of the box, freeing developers from the code-bloating complexities of ORMs, middleware layers, and typical reactive programming frameworks. This means that a database should be object-oriented by nature. It should also meet modern requirements for Big Data, distributed deployment, scalability, decentralization, as well as provide other important features, such as integrated transactional file storage, full-text search, native message queues, etc.
Such a database is on the way in Nezaboodka.
