Custom Dashboards using a 3-tier Architecture
Imagine yourself buying your dream car. One of the reasons why you bought this car was the tasteful modifications you have seen others doing. However, you soon realize that all the modified parts must come from the vehicle manufacturer and only the dealership can do those mods. This not only means more expensive modifications but also a serious limitation on what you can do to your car.
Most BI tools look very good out-of-the-box but you’re somewhat constricted to what you can do with them if creativity is your second nature and your users need a lot of customization. If you checked any of those two boxes, a custom dashboard is probably what you need to settle on, specifically, a three-tier architecture.
Three-tier architecture is a client-server software architecture pattern in which the user interface (presentation), functional process logic (“business rules”), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. [Wikipedia].
If we re-visit our car analogy, this would mean your car’s specifications are well known and third-party vendors can provide you parts as long as they match those specifications. Your headlamps have an industry-standard connector cable and you can easily buy brighter headlamps as long as they match the dimensions and the connection specification.
In a three-tier architecture, communication between the front end (also referred to as the presentation layer) and your back end (which has your business rules) takes place over API endpoints. Your front end sends a request to an API end-point (GET or POST) and the endpoint typically sends you a response in data-interchange formats like JSON, XML, SAML etc. As long as the structure of this response (like the specifications of the headlamp bulb in our car analogy) is consistent with what your front end is expecting, your front end is abstracted from what technology or business logic your back end is using.
Here is an example:
In the example above, your front-end is trying to get information about user ID 5446. It makes a GET API request to your web server with the endpoint server_address/api/user/5446. The web server processes this request and sends back the data for user 5446 as JSON.
Your front-end does not need to know what technology is used by the web server or how the user information is saved in the database. All it cares about is the contents of the JSON response. Conversely, your web server does not need to know how your front-end is constructed or how this information will be used. By doing this, you have decoupled your front-end from your web server or database technology. You can further use Object Relation Mappers (ORMs) to abstract your back-end from your database technology but that is slightly out of scope for his article.
Summary:
1. Your front-end or presentation layer is abstracted from your web server and your business logic layer. This means you’re free to choose any technology you want for your front-end or back-end as long as the information interchange format remains intact.
2. You also have complete freedom in your storage layer – you can use a relational database, NoSQL database or even a combination of the two.
3. You’re not tied to any vendor specific tools or hefty license costs
4. You have complete creative control on your front-end and technology flexibility in your back-end. You may code your API route controllers in C# today but change to Python in the future without making one line of code change in your front-end.
5. You may even choose to use Microservices if your dashboard data is coming from various disparate sources.
Here is how a complete three-tier architecture would look like:
With more than a decade of software development experience, we can provide you the correct advice and help you with your project. Please drop us a note at info@localhost for a no-obligation consultation.