David Reinert

A knowledge base platform that enables the development of feature-rich knowledge bases with completely custom themes, user experiences, and content. Countless tools and features give users full control over their content as well as the consumers of the content. Numerous metrics and reports are also made available and the account settings and customizations are endless.

A social networking application for the Juvenile Diabetes Research Foundation (JDRF), existing under their current branding. This application was built from scratch.

I was the primary architect, integrating with their existing authentication systems. The application was entirely hosted in the cloud via the Azure cloud platform. It utilized both SQL and NoSQL data stores, which were exposed via a .NET Core REST API hosted out of Azure App Service and leveraged Entity Framework Core to facilitate data access and drive database design. It also used SignalR to allow for real-time messaging and notification features.

The application UI/UX was delivered via a React-Redux SPA, built, and served as a static resource from Azure CDN. Docker was used during local development to ensure consistency and expediency for easy and fluid development environments that replicated this cloud infrastructure.

I was solely responsible for these architectural decisions, driving both front- and back-end development and implementing and maintaining the CI/CD pipeline in Azure DevOps. I served as the resident expert across the application stack, leading the team from sprint to sprint as the client's requirements grew and changed.

An employee fitness application for Citi Bank that came with an existing PHP web application was dated and not well maintained.

Without senior guidance or direction, I undertook the task of bringing the existing application codebase into the 21st century. This required pulling apart the existing codebase to separate concerns. The front end was overhauled from a complicated mess of JavaScript and jQuery into a modern Angular SPA. The PHP was refactored to function as a back-end REST API for the web and companion mobile applications.

This ensured we could deliver the kind of full-featured enterprise web application demanded by our client. It also reduced the development pain points for my fellow team members, ensuring there were fewer obstacles for them to overcome in delivering features. This required a deep dive into uncharted territory, rapidly developing my understanding of entirely new technology stacks and frameworks while regularly communicating changes throughout the rest of the team.

A chatbot platform built using the Microsoft Bot Framework and LUIS for natural language processing, integrating with numerous platforms, both text (Twitter, Facebook, Apple Business Chat, and WeChat) and voice (Alexa and Google). All of these integrations were supported by two .NET Core APIs.

The first was the connector layer, which would serve as the REST entry point for the various platforms to relay messages to. When the message came in on a given channel, the connector layer would take that JSON payload and translate it into a single data structure that the Microsoft Bot Framework could understand. It would then transmit this payload to a second API, which contained all the business logic, TD Ameritrade API integrations, and NLU processing. That API would generate a response that was sent back through the connector layer, where it would be translated again into the payload the channel could then understand and render to the end-user.

I was actively involved in development across all aspects of this system, which required thorough understanding, not only of the business rules but also the array of platforms we supported and the difference between them to ensure consistency across platforms.

AWeber provides an email marketing platform for businesses. That platform has, historically, been powered by a monolithic, legacy PHP application. AWeber started to move these legacy PHP pages to single-page applications powered by React, but this still resulted in a disjointed set of pages being served by the PHP monolith instead of a seamless user experience.

I identified this issue early in my tenure at AWeber, along with a solution: the app shell. Using module federation to load applications dynamically at run time, the app shell would be served across a range of URLs on the initial page load. From there, it would take over routing users between the various applications using client-side routing, providing a seamless web application experience. This required tackling a range of issues, from data management to styling and so on. It was a months-long effort that required dedication and determination. It is now being served to all of AWeber's customers, and the feedback has been overwhelmingly positive.