Leonso Medina

Developed an analytics dashboard app to measure the performance of title lists for movies and shows. The app was created in a monorepo. It consisted of two projects, the API and the web app. The web app was a React app with Vite and Tailwind. I used the internal component design system and React Query. For the API module, I used an internal custom Node.js framework similar to micro and used an internal client package to fetch data from a Druid database.

I led the development of a modern React, Redux, and CSS JavaScript web app. The app was a successor to a legacy Backbone.js app. The design was very outdated, hence the migration. It was hard to change the legacy codebase, considering the original developers were not at the company, and no one knew Backbone.js.

The app auths an authentication layer based on email password combination, as well as an authorization layer based on phone number confirmation. The payment gateway integration was via service API, product catalog discovery, and order placement. The app mainly consisted of a product catalog section, a shopping cart section, a checkout flow, and several account pages, such as order history, profile settings, and payment methods.

The UI/UX designer provided Figma files, and the whole team was involved in recurrent sessions with the stakeholder and designer to provide feedback and ideas for features in the app.

A helper library that bootstraps an Express.js app with minimal configuration to add custom validation, error handling, input sanitization, auth middleware, and further open customization. I am the author of this library, which is currently published on GitHub as an open-source project.

A mobile game for Android included in the game category called tower defense. I'm the author of this game, which I developed as a hobby while learning to program. I was the only developer involved in this project and I created graphical assets, audio, game design, game level design, and basic AI for the enemy units.

The Orderhero API is the product's core, where everything about the business is managed. All front-end apps consume the API, which is the single truth source. It is a monolith comprising two projects, an API service, a worker service, and a task scheduler. Each one is its service at run time, but they all share the same codebase. It is monolith in terms of source code but multiservice at deploy time.

I added role-based authorization to the API, since the original creators did not add a security layer. I approached this by introducing a configuration file for API endpoints that described the behavior of the API in a declarative way. In a way, implementing an Open API spec was a naive approach.

The API was created with a hard dependency on crane.js, which was no longer maintained after the employees left the company. I led the effort to set the dependence on crane.js in favor of express.js.

This project replaced the legacy admin panel, which was hard to maintain. Since the whole company relied on it for day-to-day activities, we created a new companion project on a modern React tech stack, which would be loaded via iFrames on several mount points in the old admin panel. This allowed users to remain in the same app and made it transparent whether the new or legacy apps were loaded. One challenge was to sync auth tokens between admin v1 and v2 since v2 was always embedded in v1. For this, we used event messages via Window.postMessage API.

The panel allows store owners and Orderhero employees to manage all business aspects, including the store product catalog, prices, open hours, delivery settings, etc.

The static site is a modern React app using our custom component library. It is a replacement for a legacy static site in Backbone.js. This site allowed store owners to customize their site with their company theme. We offered several layouts to choose from and several options to customize the experience.

Orderhero offered a feature to offload restaurant calls by directing users to the web app via a small IVR message when customers called the store phone number. The integration consists of playing a small recording under 20 seconds with instructions to access the web app and placing the order online. The recording offered callers to press 1 to receive an SMS to their mobile phone with a link to the web app.

The integration uses Telnyx (a telecom company), similar to Twilio, but cheaper. They offer a Call Control API that works via webhooks messages to receive real-time events about the lifecycle of the call while allowing them to control its behavior via their all Control API. The implementation was done in a Node.js service. The architecture of that module was to create an abstract class to represent the lifecycle of a call via its methods. Behind the scenes, there was a manager module that routed events to the respective methods for each class instance.

Orderhero had several notification mechanisms to notify users and restaurants of the order's status, including SMS, email, and fax. One recurring problem was that the previous system did not track the status of the order, and store owners and users would reach out to the support team about not being notified of changes in orders. We decided to introduce a robust notification system that consists of a default retry mechanism up to a maximum and exponential back-off, as well as a discoverable status for each notification and a manual mechanism to abort and retry beyond the default max.

The implementation consisted of a background job running on a short interval to get the status of the in-flight notifications and adding the status to the database under the entity notification receipt. We scheduled a new notification when a failure was detected, but only if the failure reason allowed a retry.

For example, an email bounce due to email address not found will not be retried, but it will be retired if the notificationfailsd due to a network error.

One of the most complex initiatives was to migrate to a new business model based on charging a fee per order versus the previous model charging a monthly subscription fee. This required several new features and integrations with third-party services.

I worked with stakeholders to understand the business goals and derive their requirements. After a few sessions, I created and shared a couple of approved UI wireframes and process diagrams with the team. The design created high-fidelity UI designs, and we devised a plan to work as a team to deliver the back-end and front-end work.

Each of the following features was crucial for the delivery of the new business model:

• Pricing schemes: A data structure that describes the behavior of the pricing model.
• Pricing packages: A set of pre-defined pricing schemes to be reused.
• Payout profiles: A data structure to define where to send store payouts and the schedule.
• Payout events: A data structure that uses the current payout profile of the store to describe a single payout event for all orders on a data range.
• Card Payment gateway: A new payment gateway provider to process credit card transactions for all orders under the new business model.

The services and apps we were hosting started to increase, and the deployment strategy was error-prone due to the need to manually set up instances with the required services.

Costs and complexity started to increase since the work was manual. I decided to approach a container-based architecture to allow us to reuse instances while using their full capacity and enable us to set up horizontally scalable policies.

For that, I decided to use AWS ECS. This managed container service relies on task and service definitions that need to be configured once. It allows updating the underlying container image as new versions need to be deployed.

Since ECS uses a pool of automatically scaled instances, the number of instances was reduced significantly since the capacity utilization for each was optimized by the ECS clients.

The welcome guide app allowed property owners to set content about their properties to be delivered to users booking the property. The app was a React app served in a Node.js service. The app consumed GraphQL with the Apollo client, and the Node.js server provided a GraphQL service via the Apollo server. The app used LESS for styles and followed the BEM principles for naming classes in CSS.

One of my contributions to this app was introducing a newer photo upload integration relayed on AWS S3 pre-signed file uploads. The idea behind this technique is to use and endpoint in your API to authorize S3 an upload for the user via a unique and temporary URL that contains all the auth parameters. Hence the name pre-signed. This allows for offloading the file traffic to AWS instead of our Node.js servers.

Then, we registered webhook listeners provided by AWS to be notified of the uploads, process the image, make it available in the different variants we need, and push an event to notify consumers that the image is ready.

I supported migrating the legacy welcome guide app to the modern react app. We needed a way to roll out the new app based on user segments.

We wanted to roll it out to all new users first, and then introduce it to users who were Vrbo employees for internal testing, and finally to all existing users of the Legacy app.

To accomplish this, we used Launch Darkly to set up a feature flag that would determine which version of the app they will see, legacy or new.

One of the tricky parts was to determine which users were new versus existing. The way I approached this was to register a Kafka consumer client on our Node.js app to read new user registration events and add those user IDs to the corresponding segmentation group. This required lots of research within the company and reaching out to external teams.

A service to store reservation access instructions. The entity was very simple. We associated the reservation ID to an object with the access instructions, supporting multiple languages. The data store of choice was MongoDB due to the need for high reads and low writes.

I created a Node.js service with Happi.js to take advantage of the company's rich internal tooling and plugin systems. The service was a simple CRUD API for access instructions, with an auth layer to ensure proper access only by property owners or users who booked the reservation.

I also created a GraphQL module to abstract consuming the service and provided an abstraction to fetch global and reservation-level access instructions. This allowed all sorts of apps to consume the module via the standard GraphQL clients used across the company. This module used an internal technique called partials that essentially were composable GraphQL modules that could be imported and mounted on servers for different teams.

I know the approach differs from the single graph Apollo Server recommends, but this is due to the internal partial standard within the company.

In the Reviews team, I added new features to the web app that I inherited. This was a reach app, and the data store for reviews was Elasticsearch, so I needed to create new GraphQL queries and mutations to fetch and update reviews from Elasticsearch.

The main feature of that app was to rewrite queries to support several filters for both the web app and the upcoming mobile apps. Filtering by unrated reservations, rated reservations, star rating, text versus star rating, etc. All those features were new, so I was in charge of writing GraphQL queries capable of returning those results. I demoed the new app on our QBR.

Another contribution that ships the Reviews Android app. I was in charge of integrating the React Native app into the host native Android app. This was a common practice at Vrbo.

The core mobile team maintained the app in Java but allowed external teams to add new screens by mounting a React Native app instead of having to implement the whole screen in Java. There was an entire build pipeline to ensure the React Native app was built and compatible with being mounted in the host app. Therefore, I was in charge of setting up the app and hooking up the Android code to open the React Native app.

I migrated the childcare booking flow to a new tech stack for faster product iteration and experimentation. Flow refers to steps designed to guide the user through the booking experience.

The app was a standalone micro-frontend, which allowed us to deploy in quick cycles and avoid the slow process of the monolith app that hosted all the products in the company.

The new app consumed a GraphQL Apollo service that provided all the data and operations for the app. The app was built with Next.js using TypeScript. The state management was handled with React Context API and apollo client. Notable library mentions include day.js for data management, apollo CodeGen to create type definitions for all GraphQL operations, and Formik to handle forms in React.

To integrate experimentation, the app made use heavy use of Launch Darkly. We used it for both feature flagging and for orchestrating A/B tests. The feature flagging integration allowed us to decouple feature releases from deployment cycles. The A/B test integration allowed us to orchestrate experiments by segregating users into groups and providing them with variations of the app specifically for the experiment.

I was hired to complete the implementation of an app that would replace the legacy system. The new app was a Next.js app using TypeScript with Material UI and Apollo client. The app hosted a GraphQL Apollo Server as part of the API functions. The app connected to the new MongoDB and the legacy Firebase RTDB.

I developed all the missing features to reach feature parity with the legacy system. I was also charged with integrating new features, such as introducing a new product system, an updated purchase log system, and introducing support for new observation lesson types.

The daycare flow was closely related to the childcare flow, but it was specific to allow users to find external daycare centers instead of an internal childcare specialist. This project consists of collecting the users' daycare requirements and sending them to daycare centers close to the users.

This integration required consuming an API service that managed and provided external day care centers available given the user constraints, such as location, budget, age of the child, and other special requirements.

The pricing flow consists of guiding the user through a flow to offer up-sells custom to the booking flow they went through and membership subscriptions with unique benefits.

This project had similar requirements to the initial child care flow project. We needed to migrate it to a new tech stack for faster product iteration and experimentation. I created a new micro-frontend app to decouple it from the existing monolith and followed the same practices as in the other projects. The main change was that we needed to integrate with the monolith experimentation framework instead of Launch Darkly.

This required us to introduce new modules to sync the state of experiments in Launch Darkly for all the other micro-frontend apps to the state in the experimentation framework in the monolith. This was the most challenging aspect of the project since it required me to contribute changes to the monolith, which was hard to develop and test.

The project was started by two founders that set up a quick proof of concept to manage all entities related to an eCommerce site. This consisted of a Loopback v3 project with already-defined models deployed to Cloud Run.

The server is connected to a MySQL database in Google Cloud. The front-end was only a set of prototypes, and I was delivered a modern app to replace the prototypes. I decided to make this service an API only and start a new project for the front-end app.

The platform allows customers to place orders from multiple vendors, enabling each vendor to accept or reject the order before the customer is charged. This required an asynchronous process to wait until all vendors had responded to the order request and allowed the user to determine whether they wanted to continue with the order. A single order can result in a payment distribution between multiple vendors. For example, vendor A gets paid for a bread bag, and vendor B gets born for organic cheese. The user only gets charged once. This integration was achieved using the Stripe Connect API to distribute payments between multiple accounts.

The app consisted of a customer-facing side and an administrative panel to manage all aspects of the business, including vendors, store details, Stripe payout accounts, product catalog, inventory management, and a tagging system to allow for product discovery. The customer-facing side was an eCommerce experience with a traditional shopping cart system and a product and store catalog search and recommendation system.

The web app is a Next.js app using TypeScript and CSS modules. It used Apollo Client to consume the Platform API, and I used CodeGen to create type-safe operations on the client side.

The API service was built with Loopback v4, and it powers the web app, which exists as a Next.js app. The API connects to a MySQL DB hosted in Google Cloud-managed database. The API is deployed to Google Cloud Run.

Image Service
The API features an image service to manage all aspects of image management. It uses Google Cloud Storage to host all image data and uses pre-signed URLs to enable fast uploads, resulting in low traffic to our services. The API offers image variants and discovery to avoid storing full URLs within the database. Instead, table relationships simply store the image ID and can use a client-side or server-side SDK to resolve the full URL based on the variant of the image. The service relies on Storage Pub/Sub notifications to process images and create variants, as well as to populate the DB Image table with the results.

Account verification via Twitter API
The site offers a feature to verify authors are who they claim to be. It does this by asking authors to publish a tweet with a special message only known to the other, and the API schedules a task on Google Cloud Task to verify that the Twitter account does publish the tweet. This implementation supports a retry mechanism built-into Cloud Task.

The admin panel and user-facing apps are built on a Next.js app with TypeScript and fully SSR. The React app uses React Context API to manage the global state, Formik to handle the form state, and React-query to manage the server state. The app is rendered on the server and hydrated on the client. This avoids having to run client-side queries unless the query is needed after user interaction, such as Pagination.

The team had already developed the app, and my responsibility was to make improvements and bug fixes. The app used vanilla React Native, styled components for styling, and Redux for state management.

I introduced feature flags to allow the team to decouple deployments from feature releases. This was especially useful because iOS and Android deployments are under the control of the individual store reviewers. This allowed the team to ship changes faster without syncing deliveries across platforms.

I introduced a fix to the Facebook login integration, which contained several bugs that did not validate all the documented edge cases.

I also integrated error reporting to a React Native app with Sentry and established on-call schedules and responsibilities for team members.

A web app that helps kids to develop reading habits through story reading. I was a full-stack developer in this project, working with a UI/UX designer and a project manager to create a responsive web app from high-fidelity design files and flows. I was the only developer for this project, so I created all features in this app.

This project consists of a management system for a university. It provides services such as allowing students to register for classes, remove classes, create a profile page, update their personal info, and show student schedules. It effectively provides all of these features, preventing users from registering for classes with conflicting schedules.

Administrators can create new classes in the admin area, edit existing classes, add students to classes, and remove students.

I was a full-stack developer in this project, and I developed it to help my university in the student enrollment process.

The app is an offering for internal administrative users that allows them to manage products, prices, regions, and purchases for users. The system uses event sourcing to track the state of accounts, such as purchased and refunded products. The state is stored in a PostgreSQL database in Supabase.com, and it relies heavily on the PostGIS extension to support geospatial operations. This is a Next.js app and a Node.js module in a monorepo configuration. The monorepo is managed via Yarn workspaces and deployed to Vercel. The app uses Tailwind CSS for styling.