Okay, so now we've talked about the back end. We've talked about the front end, and now it's time to talk about the glue that connects these two things, which is the middleware. So when a front-end user makes a request to view a particular table or visualization on our BI dashboard, the middleware will parse that request and then return the data needed for the database. So a good technology for the middleware layer is a REST API.  REST, which stands for representational state transfer, is a common architectural style used in creating Web services. 

An API or application programming interface acts as an abstraction layer. So this means that the front-end programmers, who are writing in HTML or JavaScript and designing the Web UI, don't need to understand the back-end database. They don't need to know the schema of our policy and our claims table. All they need to know is the URL for the API. And then they make a get request, which will return the data that they want in a specified format, usually a text format or a CSV or a JSON format. JSON is very common for APIs. And once the data has been returned in this expected format, it can be parsed and displayed in the front end, either as a table or used to build a visualization. 

REST APIs can be implemented in many different programming languages, including scripting languages such as PHP or Node JS or compiled languages like C Sharp, dot Net or even Go. Python, which is a scripting language, is a good choice because it's a very popular programming language. Lots of programmers know how to write in Python, having learned it for either writing APIs or other purposes, and Python has a library called flask, which allows users to build APIs fairly simply and easily. 

So now we can turn for one final time back to our Acme claims dashboard example. And now we've built the front end and the back end, and we're talking about how we're going to build the middleware and connect those two things. So you would call a meeting with your API developers in your technology division, and you would talk to them about how you were gonna build out this API, and let's say you decided to use Python and flask. Your developers say Great, we know how to use Python, that works great. They would actually look at the wireframes that were created by your UI team, which would give them an idea of exactly the data that was needed for each visualization on the dashboard, so each card that the dashboard has that you serve up, so a bar chart or a table.  Looking at the wireframes would tell your API designers what data they needed for that. And one way to do the API design is that for each card or visualization on your dashboard, you have a separate URL that calls out to the API and returns JSON data. So there's an example here, which has a Web URL that ends with slash API slash v one slash claims and that has a question mark type equals flood. And the slash claims is telling you that you want to pull claims data and then after the question mark, that's giving you an API get statement, what the query parameters are. So in this case, we're saying we only want to pull claims type of flood. So that's essentially a filter or a query parameter. And what this would do is it would pull all historical claims that are labeled as type flood in your database, and it would return it as a nice JSON object in an expected format, which then your front-end developers could parse exactly how they expected to be to display, let's say in a table so that your users could just filter through all of those claims for flood.

Lectures

Introduction - Case Study Scenario - Planning - Building the Database - Front-End Design - Claims Dashboard: Putting it Together