Story of a Startup Part 1 — Rebuilding the ship mid-flight
*This is the first article of a series of blogs outlining the decisions and implementation of a complete rebuild of the HyreCar infrastructure.*
Successful Startups tend to follow a similar growth trajectory and pattern. Everyone has seen the overgeneralized startup hype graph; of course this may not be a true representation of the route every company navigates but it does insinuate a commonality in the problems young companies face when growing at jet speeds. This story will focus on the technical challenges associated with fast growth and how our team at Novvum led a mission to “rebuild a ship mid flight”, 2018 style…
BACKGROUND
HyreCar is a fast growing peer to peer rental car platform for Uber and Lyft drivers. The growth can be attributed to a team that focused on doing whatever it took, without complaints. The founding story of HyreCar embodies scrappy and determined value creation. HyreCar empowers entrepreneurs in the rideshare industry. Of course, the scrappy startup mentality has its downfalls when it starts to take off. As you can imagine, when a shuttle built with scraps starts to get going really fast it has a tendency to shake, stutter and even in some cases fall apart mid flight…
Here is a shortened timeline and a few stats for HyreCar’s technology and team. This may sound familiar to some:
Start with an “amazing idea”
Find their first customer
That single customer turns into many customers (using a spreadsheet)
Every customer wants something different
The startup begins building more features
Features are prioritized over maintenance and infrastructure
More features also means more devs (primarily in different countries)
More devs means more complex codebase
The complex codebase starts to slow down, right as the user base begins to explode!
The infrastructure scaling issues
The company is growing but it’s insides (technology) are dying,
Expectations keep rising…
…. A solution seems improbable.
Pre-rebuild Statistics Snapshot
- 2 in-house developers
- 1 monolithic application written by 15+ devs
- 1 EC2 instance serving everything
- No CI/CD
As you can imagine, the weight of expectations and user frustration was pretty unbearable at this point. A solution seemed impossible. In a series of articles, we will outline the decisions and implementations we made to deploy two React web applications (user and admin), a GraphQL API, all new server infrastructure and a Serverless event gateway from the ground up, in a very aggressive timeframe.
PART 1 — Planning and Stack
First things first, we had to get our bearings… With limited time to plan and an impending “date” with HyreCar’s IPO looming, decisions had to be made quickly and with conviction. Using historical performance, bottlenecks and the data we had available on hand, here are a few of the key decisions we made on the stack and infrastructure. We will focus on backend infrastructure and only touch on frontend choices to provide additional context.
API: GraphQL + TypeScript
GraphQL is an open spec invented and used by Facebook for a flexible API layer. It enables faster frontend development, and fewer bytes and round trips. The GraphQL community is gaining a lot of traction and the technology is being adopted by many fast-moving companies like AirBnB, and The New York Times.
We also chose TypeScript to help us avoid a lot of simple mistakes that typically happen when using vanilla JavaScript. TypeScript helps us catch mistakes as we code rather than something mysteriously failing during runtime. There is a huge community behind it and the majority of the Graphql tools in the market support TypeScript.
FrontEnd: React
As with many companies, React provides an accelerated way to produce an excellent user experience for both HyreCar users and Admins. The React community continues to stay very active and there is no shortage of excellent libraries and tools. Our familiarity with React and Apollo’s very well designed React GraphQL Client made this decision a no brainer. React and Apollo would allow us to build faster, optimize quicker and integrate to our GraphQL server without headaches.
Apollo
Apollo is a family of technologies that makes working with GraphQL across the stack seamless. Apollo Client to connect data to the UI, Apollo Engine for infrastructure and tooling, and Apollo Server to build and serve the GraphQL API. The Apollo toolset has become the go-to in the GraphQL community due to its rich feature set and great open source support by the Apollo team. It is also being used in production by companies like Airbnb and The New York Times. The suite of Apollo tools are by far the best we have seen in the GraphQL community and a no-brainer for us to use in our project.
Database Layer (ORM): Prisma
Prisma is a performant open-source GraphQL ORM-like layer that does the heavy lifting in our GraphQL server. Prisma is the glue between the GraphQL API and our Aurora MySQL database. We implement resolvers using Prisma bindings and delegate queries to Prisma’s powerful query engine.
Utilizing Prisma saved us a tremendous amount of time on the buildout over writing manual MySQL queries. Prisma also handles a lot of the query optimizations for us and lets us seamlessly integrate the database into our schema.
Authentication: Auth0 -
Auth0 is a universal authentication & authorization platform for web, mobile, and legacy applications. It abstracts away the complexities of user authentication and provides a powerful and easy to use API to manage our users. It lets us completely customize authorization, and comes with numerous security features out of the box. It also makes integrating OAuth via Google, Facebook, and many other providers as easy as flipping a switch.
Integrations and Abstracted Functionality: Serverless -
Keeping the user up to date is a key part of HyreCar’s business. With complex user flows and a large team of customer success and sales, tooling is vital to HyreCar’s success. Serverless and Lambda functions provided an amazing foundation for quickly integrating third-party tools like CRMs, analytics tools, transactional emails and other important services, without adding complexity to the API and core codebase. The rental process has many critical steps, and using an event-driven architecture promotes a clean code base even when API logic needs to trigger multiple actions throughout the user journey.
Analytics and Data: Segment
Segment is a powerful API for integrating data tools and services into your applications and services. Segment provides an easy to use pipeline for consistent and real time data. Analytics and Data are key for a growing company’s success and with HyreCar’s limited resources and knowledge in data and analytics, Segment was a simple-to-use way to provide user and business insights. With a simple initial setup on each of our sources (clientside and serverside), we were able to collect data consistently and pipe it to the appropriate tools for analysis.
Search: Algolia
HyreCar has a consistent need for strong search functionality and as most developers know, search can be difficult to implement. Algolia provided an amazing out-of-the-box solution for us to provide performant and flexible search experiences. This was critical to serve the need for both user and admin search functionality. With such a short time frame, it made the most sense to work with the established search functionality and React library provided by Algolia.
Wrapping it up
Now, with a understanding of the stack, our goals were straightforward — rebuild the ship mid-flight. Rebuilding was exciting but also can be a long and stressful journey, we are hoping our experience can provide even a small bit of help to your team. If have any questions about our articles, feel free to reach out to our team. We would love to help and hear more.
To begin, we will explore how we constructed two powerful GraphQL servers with Apollo Server, access that data in our front end clients with Apollo Client, and continuously optimize for performance using Apollo Engine.
