A couple of weeks ago I presented at Engage on developing a React app using Domino as an API gateway and database. The slides are similar to the ones from IBM Think, just a few changes and rearrangements, so they are only posted on the Engage website.
There are a few aspects I forgot to mention.
- The source code can be found on GitHub and, since IBM Think, I’ve been through the React app and commented it in depth.
- To reiterate what I have said in the sessions, the architecture we use is deliberately not straightforward. We didn’t want a “Hello World” type demo, we wanted something closer to approximating a production environment. So there are additional technologies like Kubernetes, Istio and Agilit-e which add complexity . They may be overkill for a small app, and certainly for a demo app. But they are definitely relevant for a business-critical high-availability application where you want to better manage migrating through development, test and production environments.
- The editor for Node-RED we use is authenticated, as you would want it to be in a production environment. Authentication is against the same Domino server where the database resides. As we said, Domino is the master, not just another NoSQL database.
- Node-RED was contributed as open source by IBM.
- React was the JavaScript framework we chose. During one of the HCL/IBM sessions at Engage, there was a straw poll about preferred JavaScript frameworks. React and Angular came out as favourites developers were using, although Angular usage was split between Angular 1 and later versions of Angular. For those unaware, Angular went through a virtual rewrite for Angular 2 and is developed very differently. Popularity of Angular was probably affected by slow delivery of Angular 2 – it took more than two years to promote from beta, resulted in a number of posts asking when it would go alpha, and during that time React grew in popularity. React is very much a “best practices” framework. As someone said at Engage, you develop a React app the way React want you to. That may be a big change for Domino developers who are used to finding their own way. It’s also by no means as straightforward as other frameworks, especially when using Redux for state management. The other JavaScript framework in popularity was Vue, and that is most certainly more straightforward than React.
- From my personal experience, React would be slower to develop with than XPages. The structure of the application is also quite complicated, with React components, reducers and state management. The inter-relationships of various JavaScript files reminds me of Salesforce applications that use Lightning components. Good documentation is more critical than Domino developers would probably be used to and some Domino developers may struggle with it, especially if not developing with React regularly. In my opinion, XPages still has a place for those who have embraced it, particularly for rapid application development and integration of things like Dojo charting. Similarly Notes Client development still has a place (even more with Domino 10), the low code development we will see in Domino 11 will have its place too, and JavaScript framework development against Domino will certainly have a place for a new audience.
- I used Visual Studio Code for reviewing and amending the React app, WebSocket server and Agilit-e server. This was the preferred IDE for developing web applications at that same HCL/ICM session.
- I used Eclipse and the ODA Starter Servlet as the basis for the REST service plugin. With the JavaScript DominoDB NodeJS module with Domino 10, and a similar module for design, the same app could be built with just Visual Studio Code. And that module could be developed by the community – if required. After all, creating or replacing design notes can be done via DXL.
As with many sessions I’ve been involved in, this has been very informative and has taught me a great deal that I’m sure will be useful over the coming years. It’s opened up a lot of potential for applications or microservices, whether on premises or on the cloud.
