Our goal at Info Rhino is to keep our websites as open to content and data update as possible. We seek to reduce external dependencies, and focus on content optimisation strategies. At the same time, control over who provides content is vital, but we reduce the burden of centrally managing this. This permits individuals not skilled in website design to update information on your website.
This article details some of our approaches used in improving data driven websites. Some may be obvious, some will be explored in other articles.
How we have made our development experience in ASP.Net Core far more effective, and improved the quality of our applications.
When we try to do things the way industry practice says to, often we end up with a continual need to add new endpoints per requirement, which can result in rebuilding and redeploying the application. Whilst good for Domain Driven Design and Restful design needs this, consider building dynamic/generic get methods.
ASP.Net Core has magnificent caching capabilities, and yet most developers stick to using Entity Framework. Why? We have gone as far as to cache our reports, certain view component content, and references to articles outside of a database. We suspect we can use a distributed cache across multiple servers if required.
Most ASP.Net developers fire up Entity Framework, start building a database counter to good Entity Relational Modelling design, and stick their dbContext with Linq inside their fat controllers.
We use Dapper - a great ORM which can return multiple datasets per query. This is perfect for delivering data in json data objects to clients through an API, resulting in less round trips to the database server.
You will note we use caching too.
One of the biggest temptations is to stick lots of pages in menus driven off of a database table. This can result in information overload, and force the user to try and remember what is in each menu. Worse - web crawlers are going to struggle with indexing continually changing navigation. Any Data Driven pages (endpoints) should be the receiver of arguments to display context specific content and reports.
Never ending menus and mysterious content on hover is known as "Mystery Meat" - you don't know what you are getting.
You may notice there are no menus in our page menu bar, and you may ask why? Our Web Data Platform (WDP) contains the ability to have menu items, so why have we decided against it? We see it that users who regularly access features benefit from menu access. When we expect regular footfall to a website, who aren't as certain as to what they are looking for, users don't want to be constantly be hovering over menus trying to guess what a page contains.
So we have extra landing pages with static menus (cells with links) within them. Our objective is to see if these pages themselves are found directly by web searches.
A quick example;
Child pages;
Landing page contains the above text, with links and extra content.
Is it possible that web searches including,
Database Website Content Development will get hit?
We put a huge amount of development hours into thinking through problems as in this article. Completely rethinking our approach. This translates into saved development hours and cheaper website implementation for clients. We are looking at increasing ways to work with partners to improve delivery to clients.
Partnership - selling for Info Rhino
Written with StackEdit.