A word from the author
If you wish to learn more about this then please go to our contact page to find out more.
Abstract and rationale for plugin capability for websites
One of the challenges with Developing websites is the need to maintain content and develop more functionality within the actual website code. This means you know case updating C# code and publishing it the website to a local server before dropping the website online via FTP or some other publication process. We're at the point where we have continuous integration running on three of our multiple websites locally. We developed our own software for this purpose and you can read more about it here Automation and Devops .
Another major challenge with website development is maintaining content in conjunction with releasing new code based functionality to the platform. In this area we think we have it largely solved. We use Piranha CMS content management system in .Net Core to maintain content which are either rendered via;
- cshtml razor views
- Content from configuration
- Dynamic Data
- The content management system
We have developed generic view components. The goal of our platform is not to have domain specific logic within it. Instead we focus on generic capabilities that can be pulled into the website for different target audiences.
When working with junior developers and those less experienced in solution and data architecture the temptation is to start developing within the website solution. These domain specific components then end up within the website until we have to maintain different versions of content and application logic for different customers. As we can see this does not end well becomes hard to maintain and doesn't define clear boundaries between different customer requirements.
The obvious solution, let developers work in their comfort zones and improve their skills where they see best. Developers can build applications without having to understand databases or Server Side architecture. Those experts in databases, document stores, APIs, messaging architectures, and server-side architecture can stay in their area.
In keeping with our approach to droppable data, we have already incorporated plug in capability to our platform, and are now in a position where we can add MVVM JS clients that can themselves be configured and dropped into a website without being resident within our main code base. (We obviously do retain any client size code within source control but there's a difference between the generic implementation and domain based functionality.
The different capabilities for dropping plugins and applications into our web data platform
Tabbed snippet loader
These snippets are retained in-cache.
We have provided the capability to define simple HTML files that can reference external resources. These tend to be widgets from other websites. For example we can incorporate data from trading view and other Twitter content providers to help bring her own website at Crypto Statto alive. Please define quite large content items that can become visually appealing and useful to our audience without them having to leave website.
JS application plugin
Traditionally we have worked with knockout JS for our MVVM development and long may we continue to do so as it is an excellent framework. We have been adding react JS applications to new platform and incorporated an effective mechanism to plug these applications into a website. This is entirely configuration driven and part of the release process. The power of this capability is we are now in a position to allow third parties to create their own applications to feature within our web data platform (given security acceptance and data quality standards).
The significance of being able to drop applications into a website
We are now able to separate the different technology layers of a website application. For example we work with Bytes Reality who specialise in MVVM and client sized website applications. We can now ask third parties to develop client applications without them having to understand our web data platform which is in dotnet core. Similarly where it comes to serving content via APIs we can either spin up a new API on a separate server or potentially one of the cloud hosting providers such as a WS, Google cloud platform, or Azure, or at this generic API feed to own web data platform.
Division of responsibilities becomes easier therefore
So the real advantage is we can manage the overall process of implementing a web data solution but work with experts within a particular domain without necessarily having to go through the full on boarding process to get then to understand the entirety of our solution.
We can just set standards, give some basic pointers, and even spin up a The website where the developer can drop their applications to test how the solution will work.
The main advantage of our approach is that our clients can now build their own applications, and drop their own content into our host web data platform, and not be completely dependent upon us to add extra features and functionality to their website.