The client develops software products to help Fire & EMS departments improve their response times, optimize their resources and defend their budgets.
The client already had an app that simulates and tests complex dispatch policies for Fire & EMS departments before going live. Their configuration process for the app was entirely manual and involved sparing with their in-house analysts and resources to manage and control their customers’ data which wasn’t really productive or beneficial.
Their customers used to send information to them and wait for them to update this information in the backend manually. They would then have to go to the main application, run a few simulations and verify that the data provided was accurately updated. It required a few iterations to get it right, which resulted in multiple back-and-forth emails with data and a huge turnover time for a rather simple information update.
The client needed assistance developing a builder tool for the main/parent simulator application.
The primary goal of this application is to create an administrative/configuration portal for their customers (i.e; Fire and EMS departments).
The application should enable the Fire & EMS departments’ staff to manage a lot of their internal metrics and also run simulations to look at the performance and responsiveness of each of their various teams.
The application should be built from scratch with custom UI similar to the parent application so that the users do not have a big learning curve for the same.
We developed the builder application as an extension of the simulator application and styled every component as per the client’s branding and style guide. This project was unique in the way it was built (i.e.) as a child application that transitions from its parent seamlessly without the user knowing that they are migrating to another application. Though the application was built independent of the parent, it was built in a way that it could be tightly coupled once it fully developed, tested, and deployed.
We first structured the project’s folder, and created separate code repositories for the backend and frontend individually.
An important aspect of the application was single sign-on so that the user who moved from the parent application to the builder application was always logged-in and did not notice moving between multiple applications. Both the backend and frontend were developed in order to make this happen seamlessly.
Here are some solutions we provided for the challenges we encountered while working on the backend of this project:
Working with shape files: Some of our biggest challenges with this project was related to working with shape file data. Reading shape files, transforming shape file data from one projection to another, and finding ways to get this done using C#/Postgres DB was seldom straightforward. After a lot of strategy and consulting sessions with the client, we used PostGIS for dealing with Geographic Information Systems (GIS) data. Using the PostGIS plugin for Postgres, we could read, transform, write and do many more GIS related operations.
Dealing with complex DB relationships: We worked with a complex DB relationship schema which was already created by the client team. We suggested several database best practices to work with complex database relationships which the client really liked and hence readily adopted not just for this project, but for all other projects within their organization.
Project Logging: We faced unique challenges while logging information about each call to the database. As this was introducing additional load, it led to a slowdown of the entire application. In order to address this, we implemented asynchronous logging.