Bistrobo

Bistrobo is a product I built for the restaurant industry. The app provides restaurants with a responsive online menu that customers can use to place orders. Restaurants also get an admin portal which they can use to manage their menu, orders, hours of operation, and more. Bistrobo also comes with automated text notifications and payment processing.

This project began when a friend of mine needed a better online ordering app for his food truck. Quickly, I realized that there was potential to turn this project into a SaaS product.

You can see a demo menu here. To learn more or to see a demo of the admin portal you can send me a message through my Contact Form.

Tech Stack

Both the admin site and customer facing menu are single-page-apps built with Vue. These apps connect to a rest API build in express. The back end uses MongoDB hosted on Mongo's Atlas.

Bistrobo also makes use of several external APIs: Payments are handled using Square, Twilio is used for text notification, Images are stored and managed in an AWS S3 bucket, and emails are sent using SendGrid.

Lessons Learned

I ran into some challenges while building this app. Building an app that could handle payments, photo uploads, multiple clients, and more brought a whole host of complications. Integrating many moving parts into one coherent application was a tough and rewarding project.

OAuth

Before I could use Square's payment API, I had to work my way through an OAuth authentication flow. It took some time and research to fully understand the intricacies and details of this protocol.

After gaining a full understanding of OAuth flows, I was finally able to authorize my app with Square. As trying as the process was at times, I really enjoyed learning about how OAuth works, and why it is necessary.

OAuth Flow Diagram

Planning for Scale

I also had to figure out how to build my app in a way that would scale. At first, I was deploying an entirely separate instance of the app for every client. This is called 'Single Tenant Architecture', and knew that it would be an inefficient system to scale as the project grew.

To solve this problem, I deployed a 'multi-tenant' architecture. In this system, a single Node server was used to handle multiple clients, and manage multiple database connections. This was not as straightforward as I hoped, but through YouTube and Stack Overflow, anything is possible.

Single-Tenant Architecture

Multi-Tenant Architecture

Storing Sensitive Data

One unforeseen issue I had to address in this new architecture was where to store sensitive tokens and keys. In the single-tenant solution, client specific keys could be stored in environment variables on the server. When moving to a multi-tenant architecture, I knew that it would not be feasible to manage a growing list of tokens stored as environment variables.

The solution I settled on was storing these tokens in a database. I took extra care to secure this database, encrypted all of the sensitive data that was being stored there. I then saved the encryption key as an environment variable on my server.