2DX est un framework d'interface utilisateur Web qui se compose d'un navigateur NoSQL en mémoire et d'un SGBDR hébergeant un interpréteur JavaScript construit par procédure stockée. Les composants de base de données NoSQL et RDBMS de 2DX suivent le même schéma de base de données Entity-Attribute-Value conçu pour accueillir les données sérialisées sous forme normale. Il a été développé par réductionnisme des modèles de données relationnelles aux formats de données sérialisés trouvés dans les normes de l'industrie comme XML ou JSON.
Le client NoSQL pour les navigateurs Web est un objet singleton JavaScript léger qui est une base de données fournie avec une interface de requête de données sérialisée indexée pour la réduction de la notation Big-O dans les opérations d'extraction. Différents types de documents sont pris en charge par les pilotes d'API pertinents. Le type de document actuellement pris en charge est « UI » pour les arborescences DOM du site Web avec prise en charge de « DB » pour les données relationnelles et « OL » pour les tableaux croisés dynamiques en cours de développement. Le client 2DX s'interface avec des frameworks JavaScript tiers tels que Angular ou jQuery via des pilotes d'API spécifiques étendant ses fonctionnalités d'interface utilisateur client aux outils de développement Web largement utilisés.
Les pages Web contenues dans l'arborescence DOM du document "UI" sont affichées sur les écrans via le moteur de rendu et de mise en cache HTML intégré. Pour ses opérations d'interface utilisateur, la base de données NoSQL du client crée un conteneur DOM en mémoire au moment de l'initialisation "new JS2DX()". Cette fonction permet un accès direct à la mémoire DB-UI. Les benchmarks montrent que 2DX peut rendre plusieurs pages Web à des intervalles de 10 à 20 millisecondes et est capable de charger des arborescences DOM avec plus de 2 millions d'éléments HTML sans planter la fenêtre du navigateur.
Le serveur 2DX est une base de données RDBMS hébergeant des procédures stockées qui convertissent les données sérialisées en forme normale et vice-versa. Les procédures stockées représentent un interpréteur JavaScript dont le code source du programme est stocké sous forme normale. En plus de valider les données client soumises, le serveur 2DX est capable d'exécuter des programmes orientés objet complets, compatibles avec la logique métier, écrits en JavaScript fortement typé. Il se connecte aux instances client via le pilote CGI.
Alors que de plus en plus d'entreprises choisissent NoSQL pour des performances de requête rapides, son interopérabilité avec les données relationnelles est souvent laissée à la couche intermédiaire de l'application. 2DX élimine le besoin d'une couche intermédiaire avec un environnement de programmation hébergé dans des modules stockés persistants natifs du RDBMS. Les données soumises par les clients sont traitées et enregistrées par une base de données relationnelle. Les journaux de transactions avec des lignes de table mises à jour sont publiés de manière asynchrone sur un serveur ou un système de fichiers NoSQL. Les instances de base de données client utilisent ce dernier pour récupérer les journaux des mises à jour des données relationnelles pour la réplication et la disponibilité instantanée sur les écrans de l'interface utilisateur. Une fois que les transactions en attente sont lues sur les instances client, elles sont synchronisées avec la base de données du serveur.
La configuration du cluster de bases de données client/serveur 2DX garantit une faible latence dans les environnements de données volumineux où la validation des requêtes client vers une base de données relationnelle est nécessaire. De plus, un tel cluster garantira que les opérations d'entrée/sortie de l'utilisateur sont enregistrées dans les journaux de transactions RDBMS. Ses performances de rendu de l'interface utilisateur peuvent ouvrir 2DX pour une utilisation dans les services de jeux Web. L'envoi direct des journaux de base de données entre les composants de base de données client et serveur du cluster qui contourne la sérialisation et le serveur SGBD propriétaire en remplacement du SGBDR générique est prévu dans les futures versions.
