Domino 10 App Dev Thoughts – Be Scared, Be Excited

Home » Domino 10 App Dev Thoughts – Be Scared, Be Excited

Today’s webinar on Domino 10 brought a lot of announcements. I won’t cover the announcements about Notes Client here – we were teased about a slimmer client and auto-updating of that client, but I’m sure we’ll find out more at IBM Think. I’ve already blogged my thoughts about the Notes Client as well.

There are more small but beneficial user improvement enhancements about mail and calendaring. Personally my mail client has been Verse for a while now, so hopefully they will also be available there. Verse is not yet perfect or fully feature-comparable, but it’s changed my mail and calendaring experience for the better.

The big announcements were around app dev.

In terms of the backend, there were some significant announcements like increasing database size to 256Gb. Personally, with DAOS and now externalisation of view indices, and particularly with the changing application architecture that has come from XPages or other web applications, the current size limit has not been a problem. But I’m sure this will be welcomed. Repair and monitoring improvements will also be beneficial for admins / devops. There were also a lot of announcements around flexible security and authentication options, and oAuth was announced as part of the future feature-set. Admittedly oAuth is something I’m only touching on at the moment, mainly through Watson Workspace. And it’s still a flow that confuses my little brain a bit. But there are obvious areas it would have significant benefits, both from Domino and from external solutions.

Improvements in full text search updating and resilience was interesting but, in the context of search, overshadowed by the announcement of ElasticSearch. There were rumours of this being investigated in the context of Verse on Premises and it’s been an obvious potential enhancement that no one in the community has took forward – or, if anyone has, they haven’t chosen to share it. I admit I don’t know much about it. I’ve heard it mentioned frequently, as a standard tool outside the yellow bubble and the candidate usually mentioned for replacing full text searching. I don’t know how hard it would be to integrate, how to set it up, what else would be required or what its limitations might be (rich text?). But it’s welcome.

There will also be Docker Enterprise Edition images. Docker Enterprise Edition is not a free option, as far as I’m aware. But Domino on Docker is another good step forward. Gab Davis made a good point at the UK Domino 2025 Jam, that Docker will bring strongest benefits if different Domino services can be surfaced through different Docker containers. I don’t know if that’s possible, but I’m pretty sure it’s not something that can be delivered in the Domino 10 timeframe. But what we have is a good step forward and I think IBM can appreciate the reasons why splitting services across Docker containers would be beneficial.

The biggest announcements were around NodeJS and LoopBack support for Domino. I’ve installed a few npm packages since IBM Connect last year – Swagger Editor and Swagger UI, Node-RED. NodeJS is popular for very good reason, even I as a Java developer appreciate that. And Swagger and Node-RED are tools I have actively used and will be using in my upcoming IBM Think session with John Jardin. I don’t know much about LoopBack, but from the answer to my question on the webinar, it will be critical to overcoming my concerns about DAS. These finally open up Domino to JavaScript developers, something which I believe is critical to expanding the platform.

What I think was a key term in the webinar was “NSF-2”. Not “Notes-2”, not “Domino-2”, “NSF-2”. NSF, the datastore. It’s always been ahead of its time – NoSQL before there was anything beyond SQL; social before the term existed because it did collaboration; offline before, after, and before (again) offline access was needed; dependable replication before distributed databases existed; full stack before some full stack developers were born; “in the cloud” through hosting companies like Prominic before cloud existed. And then there’s the workspace layout that Apple made so popular. The push is to make the NSF a player again, and the integration of NodeJS, LoopBack and ElasticSearch are necessary steps for that. What your UIs are and where are less relevant – and today there are more and more scenarios where one ui (pun intended) is not enough. So focusing on a specific front-end framework – especially  if we’re talking about including JavaScript developers – is a thankless task. The backend and the full stack has always been its strength and what will grow the user base.

One elephant in the room here is what this means for Rich Text. Rich Text is the data equivalent of a Notes Client application: everything is bundled together, presentation layer and content, and therein lies the problem. Once your app is outside of Domino, all you want is the text and, at best, some semantic information like these are bullet points or this should be emphasised or this is a second-level title. Wherever the text is displayed should handle how those semantics are formatted, in order to be consistent with the rest of the application. It’s the remaining proprietary artifact, without an obvious well-integrated alternative. Personally, for me, MarkDown makes more sense in a future world than Rich Text.

Does this mean Notes Client development or XPages or Java development on Domino is dead? No. XPages is still quicker development than other options for a complete self-contained solution. And with the knowledge I’ve gained over the years of what’s happening in the infrastructure and lifecycles, it’s easy for me to manipulate. And the move from SSJS to Java was most definitely the right approach to enable all sorts of extensibility and flexibility. Java currently allows me the kind of flexibility required for managing my application, data and background tasks most effectively for REST access. So these areas are all much more fully-fledged than JavaScript development on Domino. If you’re planning to build the platform, better supporting JavaScript developers is a must and it’s a case of getting it up to the same level of support, so it’s a no-brainer that this is where most effort is being placed. And it benefits pre-existing apps as well, for allowing easier integration beyond just Domino.

As you’ve probably seen from this blog post, what this does mean is a lot of new technologies and tools for application development. Domino has historically been very proprietary and closed to the outside world. The “yellow bubble” and its community has been criticised by many for not stepping outside of NSF-development. And those who have wanted to do so have often struggled against a lack of integration with external standard technologies. No longer. But this means if you really want to leverage the future, it’s time to bite your lip, swallow down that sickly taste that is fear of the unknown, and start learning new these new technologies. The good news is that, like I’ve seen with a fair amount of XPages and with a lot of the Java libraries I’ve used, I expect it to be implemented in a standard way. So the blog posts from outside the yellow bubble will be relevant. It’s scary, but exciting times, no doubt with a lot of opportunities if you’ve been looking for an opportunity to get involved in blogging, speaking or more. I would strongly encourage everyone to embrace the technologies and opportunities that will be coming along.

The other good news is that the announcements fit in with the direction John Jardin and I have taken for a session we were asked to deliver at IBM Think. The session is “Tips and Tricks: Domino and JavaScript Development Master Class“, Mandalay Bay South, Level 2 – Surf B, Thursday 22nd March 10:30 AM – 11:10 AM. I suspect it will also be submitted for other conferences through the year and popssibly elsewhere. The demo application we’ll show showcases Domino at the heart of a multi-technology JavaScript application. It doesn’t yet use LoopBack for the API gateway, but has Domino as the master and uses technologies like Swagger, Node-RED, Docker and more. Plus, for those who are not enamoured with Domino Designer, the whole app is built, deployed, secured and managed without any integration with the Notes / Domino Designer / Domino Admin client – to prove that you can. It fits well with NSF-2, it’s Domino in a microservices architecture…on steroids, as an extreme example of what is possible. And if we can, there are secondary goals we have for even further integration, to highlight the benefits of this API-first approach.

6 thoughts on “Domino 10 App Dev Thoughts – Be Scared, Be Excited”

    1. Domino is evolving. I think anyone who makes a comment on being excited or not needs to qualify it by what kind of apps they intend to build, with what tools, what languages, where and for how long. If it’s Notes Client apps only, traditional “suck data, send data” integration to external solutions, small NSFs, standard searching, Formula Language and LotusScript and Domino Designer – I agree, nothing to be excited about. If it’s XPages with SSJS, never stepping outside the NSF, LotusScript agents for scheduled processes, small NSFs, standard searching, Domino Designer – I agree, nothing to be excited.

      But if you want there to be a future for this platform, your willing to try new things, learn new technologies, you were for example excited by the idea of XAgents triggered by Node-RED to finally allow you to run scheduled processes without relying on LotusScript but were daunted by trying to get a separate server for Node-RED in dev, test and live – this should leave you excited. There are many people complaining about Domino Designer. This announcement paves the way for building an end-to-end Domino app without opening Domino Designer, if you want to build that way.

      Don’t blog about your first “Hello World” react app on Domino. First decide what front-end framework you want. Then learn about LoopBack and see whether it provides the API gateway you want – the app needs a back end, and assuming your using Domino’s in-built database, LoopBack is just one method of building REST services, as I’m sure you’re aware. Then think about your scheduled processes – most migration-from-Domino examples I’ve seen over the years deliberately miss that part out, but it’s integral to how we’ve historically designed apps. Then think about the authentication method you want for your app – when front end is separated from backend, there is greater flexibility. Read the blog posts I’ve done on Node-RED, the ones I and Stephan Wissel have done on Swagger, the ones others in the community have done that may be relevant that I’ve not paid enough attention to because they were beyond the scope of what I did with Domino in the past. Finally, realise that unless I’m misunderstanding the architecture announced yesterday, you won’t be building a React app on Domino, so there’s no point blogging that. You’ll be building a React app on NodeJS that’s delivered with Domino. And there are a host of blog posts already about building a React app on NodeJS, so then check whether there’s anything your blog post would add.

      This is precisely why I’ve said there’s a lot to be scared about and why a lot of developers will need a lot of support from their managers, from business partners and from IBM to modernise their skills. But if you’re willing to embrace new technologies and tools and skills, I strongly maintain that there was plenty yesterday to be excited about.

  1. Hopefully I will be selected to present at engage. Then I will be showing what we at PSK are doing with React on node.js running on same machine as Domino which is the backend with an API we developed using openNTF Domino API. We also integrated mongoDb to handle some of the data needed to run the web client.
    That sid, the news from IBM/HCL is really exciting for us.

    1. For a few years I am using Domino as NoSQL data container only. As the REST framework I am using Spring Boot (which is running as a OSGi Plugin on Domino).

      In a company (which is migrating Domino for more then ten years) and my applications should be replaced with “newer” technologies.

      So I never used the term “Lotus” or “Domino” again in front of the decision makers, just “NoSQL”, “Microservice” and “Spring Boot”. The frontend is running on nodejs. Since then, all are happy, because they are working with the latest hipster technologies…

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top