Skip to main content

The iPhora Journey - Part 4 - JSON is King - The Why

The iPhora Journey - Part 1 - Reimagining Domino

The iPhora Journey - Part 2 - Domino, the Little Engine that Could

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 4 - JSON is King - The Why


JavaScript Object Notation (JSON) was defined by Douglas Crockford in early 2000s as a data exchange format that grew out of JavaScript. JavaScript code can in fact be structured as JSON data, and even the HTML DOM can be represented as JSON data (more about that in a future blog).




JSON has now become the dominant data exchange format, superseding XML. It provides data exchange between the server and JavaScript-based clients, including web browsers, and it is also used in web services and web hooks. It is not only readable by humans but it is also lightweight. Databases such as MongoDB and RavenDB use JSON as the data storage format, and there are a number of derivatives, such as BJSON, a binary version of JSON used in MongoDB.

More and more companies are relying on either cloud-based or external web services to operate their business, and 99% of all web services rely on JSON. So the importance of being able to process, store, and manipulate JSON is essential for any web application server. When we started this journey, the only thing in Domino that supported JSON was the ReadViewEntries call (with OutputFormat=JSON), and that was it.

As part of our quest to reimagine Domino, we wanted to have Domino behave like a modern web application server, specifically, a JSON-based NoSQL database platform, similar to MongoDB. Note that Domino has many advantages over competing database technologies. A Domino document can be up to 2 GBbyte in size, while MongoDB has a limit of 16 MBytes. Domino also supports master-to-master replication and has a more robust and more granular data security model. So we had to figure out how to send, receive, and store JSON data in Domino.

Another factor in our decision to transform Domino into a JSON-based NoSQL platform was portability. At the time, it was not clear how much longer Domino would be supported by IBM (a question that was happily resolved when HCL acquired Domino), so we needed a design approach the was platform agnostic. Again, a JSON-based NoSQL design (one that was API-driven) would achieve that. It would have separation between user interface and data store, making it much easier to move to an alternative data store if necessary.

We decided to break this part into two posting since it was getting too long. So, tomorrow, The iPhora Journey - Part 4 - JSON is King - The How. 


The iPhora Journey - Part 4 - JSON is King - The Why

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 2 - Domino, the Little Engine that Could

The iPhora Journey - Part 1 - Reimagining Domino

Comments

Popular posts from this blog

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework There are many ways to create the user interface (UI) for a web application. The HTML page could be created on the server and then pushed out. It could be static with the data generated on the page by the server with JavaScript, providing a more dynamic experience, or the server could generate new HTML content to update portions of the web page. XPages or PHP are good examples of this. Another method is to have the web page partially generated by the server and have JavaScript build the rest of the HTML by pulling data from the server via an API. This is the approach used in the Single Page Application (SPA) model. In all cases, it is still dependent on the web server technology being using.  As mentioned previously in this blog, XPages is dependent on complete integration between form and document, which e