If you wish to learn more about this then please go to our contact page to find out more.
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;
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.
Software developers have their specialisms despite the attempts to make them more multidisciplinary so agile project approaches. A major sticking point with incorporating new developers onto our platform is that they tend to be developers in a stack which isn't using dot net core MVC. We prefer them to be experts in Csharp/C# but they prefer to be developing in one of the JavaScript frameworks. The Model View Controller using razor is a good approach to developing website applications but other developers do not like this approach.
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.
Developing client-based/JavaScript website applications to run within a website is more common than we can expect. Many websites will include snippets from other website providers to boost functionality and features within their solution.
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.
We define snippets which may include JavaScript, CSS, and HTML files, linking to them to the slug/page where they are to appear. The beauty of this component is we can incorporate multiple snippets just by clicking on the bottom and it will load in-page asynchronously.
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.
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).
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.
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.
Thank you for taking the time to read our article on removing dependencies on JavaScript applications within dotnet core website MVC development.