Developer Meeting: June 5, 2024 at 12:00 PM ET

Status Updates

5.1.2 released on May 28, 2024

• 68 Pull Requests
• 144 Commits
• 9 Contributors
• 1 New Contributor

Contributors: @sbwalker, @zyhfish, @mdmontesinos, @leigh-pointer, @ohba-ikuo, @ijaz-saeed, @iJungleboy, @vnetonline, @marceloatoledo

9 contributors is the highest number that the Oqtane open source project has ever experienced for an individual release. This level of participation emphasizes the growth and enthusiasm of the Oqtane community.

The 5.1.2 release was a maintenance release. It included a variety of user and developer experience improvements, performance optimizations, localization updates, and enhancements for Blazor Static Server Rendering.

Extreme Makeover: DNN Edition

A webinar was hosted on May 29 which was focused on the current state of DNN, content management system (CMS) migration challenges, and why Oqtane may be a viable path forward for users of DNN. The webinar recording can be viewed on YouTube.

Rich Text Editor

In the previous Oqtane Developer Meeting there was a discussion about rich text editors. Initially there was a proposal to upgrade to the new version of Quill, however there was also a proposal to migrate to a completely different rich text editor. @adefwebserver shared the progress he had made on creating a rich text editor for Oqtane using the Radzen Editor component. @ijungleboy also shared some of his past experiences with rich text editors and highlighted a number of use cases and risks that need to be considered. Overall the consensus was that different users will have different needs, so the most practical way forward is to add an extensibility model so that alternate implementations can be created and easily integrated.

Scalability

During the 5.0 release cycle a lot of focus was placed on the performance characteristics of the Oqtane framework. In particular, static rendering offered some very significant performance benefits in scenarios where interactivity was not required. One of the most common techniques for improving performance is to use caching... however there is a delicate balance between caching and scalability. If you cache information it will improve the performance of your application, but if you cache too much information it will consume all of your available RAM in your environment and will cause scalability problems.

Recently there has been an effort by @zhyfish to test the scalability aspects of the application. This was accomplished by creating a site template which can generate hundreds of pages and modules within a site.

The scalability testing revealed that if you had a site with thousands of module instances, you could run into some resource constraints. This was caused by the eager loading approach where a collection of all modules in a site were being loaded into an aggregated Site object which was then being passed from the server to the client and made available to components as a cascading parameter. The size of this object was a problem from a variety of perspectives, including memory management as well as serialization/deserialization.

As a result, a modification was made to the framework by @sbwalker so that it no longer loads the entire collection of modules for a site. Instead, it only loads the collection of modules which are associated to the current page. This reduced the resource requirements and significantly improved the scalability. However, it also means that if developers were relying on the PageState.Modules collection to provide a list of all modules in a site, they will likely need to refactor their code to use an alternate method.

Search

Most frameworks which manage content require some type of a search capability which allows users to quickly locate information within a site. This feature had been on the Oqtane roadmap for a long time and it was recently prioritized for inclusion in the next release.

The high level goals for the search capability were outlined as follows:

• Since Oqtane and DNN share a similar approach in regards to the storage of content, incorporate lessons learned from the previous DNN implementations
• Since 95% of sites/apps only require basic lexical keyword search functionality, focus on this minimal use case in the default implementation
• Follow the Oqtane Philosophy to ensure that the default implementation has minimal third party dependencies and minimal infrastructure requirements
• Ensure the default implementation can be used cross platform and is database agnostic
• Include extensibility to support other custom search implementations

The diagram below outlines the high level architecture approach. The extensibility model is based on a SearchProvider which is responsible for storing information and retrieving information. The default implementation will use a standard inverted index stored in the Oqtane database. Other implementations might want to use cloud services such as Azure Cognitive Search or a file based approach such as Lucene.

Roadmap

Based on the major optimizations and enhancements outlined above, the next version of Oqtane will be a major release - version 5.2. The expected time frame is July 2024.

The next Oqtane Developer Meeting will be on July 3, 2024.