5

What's the architecture of Taro?

Profile picture
Software Engineer [E4] at Aptos Labs2 months ago

I am trying to get better at System Design and trying to understand the design of various systems. I'm very curious about the System Design of Taro, and how Taro is built.

  • What technologies are used for frontend and backend?
  • What is the backend architecture used? What are the databases used?
  • How are the videos streamed, payments handled, user logins handled?
  • How does Taro scale with users and give a smooth experience?
  • How is the platform optimized from the perspective of cloud costs?
  • When the number of users on Taro increases by an order of magnitude, what are the changes to the architecture you would consider doing?
  • Is the website built from scratch? Or are there any libraries and frameworks available to make it easier?
  • Taro seems like a well-built platform with smooth user experience and a lot of features. I'm surprised that all of this built by just one engineer (Charlie). What's the secret sauce? What are the tradeoffs made to still make things work with less resources?
  • What is the decision-making process that went into making all these decisions?
70
2

Discussion

(2 comments)
  • 1
    Profile picture
    Eng @ Taro
    2 months ago

    A lot of our system design choices were made to maximize product development velocity because we are a small team with limited cash.

    What technologies are used for frontend and backend?

    We use Next.js for our frontend and our API layer. We use Firebase and Google Cloud services on the backend.

    What is the backend architecture used? What are the databases used?

    We use a RESTful API architecture + Firebase SDK for reading and writing data. Our API is used for shared business logic between the webapp and mobile apps or exposed to third party services for webhook logic.

    We use Firebase for our database.

    How are the videos streamed, payments handled, user logins handled?

    Videos are streamed through Firebase.

    Payments are handled through Stripe

    User authentication is handled through Firebase Authentication.

    How does Taro scale with users and give a smooth experience?

    Since we use Next.js, we try to build and cache pages as much as possible.

    How is the platform optimized from the perspective of cloud costs?

    From the previous answer, making use of Next.js SSG and ISR everywhere we can helps with minimizing the number of calls to our database. There are more optimizations that we could be doing, but, Firebase is still pretty cheap even when unoptimized. Our time and resources are better spent iterating on the product than trying to optimize the infrastructure.

    When the number of users on Taro increases by an order of magnitude, what are the changes to the architecture you would consider doing?

    We might even consider using the same architecture for the webapp because the Next.js caching is working out enough for us enough where increasing by 10x doesn't necessarily mean that our costs will increase by 10x. Cloud platforms are so nice for ensuring stability and reliability at a reasonable cost where it makes more sense to focus on developing a better product.

    Is the website built from scratch? Or are there any libraries and frameworks available to make it easier?

    We stand on the shoulders of giants. There are so many great open source frameworks and libraries that we use, like Next.js and Vercel that automates the build and deployment process for us.

    Taro seems like a well-built platform with smooth user experience and a lot of features. I'm surprised that all of this built by just one engineer (Charlie). What's the secret sauce? What are the tradeoffs made to still make things work with less resources?

    I really appreciate those kind words! I think a lot of it comes down to being very intentional about whether we can leverage existing tools instead of building them ourselves, the "build vs. buy" argument. There are so many great services out there offering their products at very reasonable prices. We do try to go with the "buy" side as much as possible because you can essentially pay $xx-$xxx to do what it might take many months or years to do with many more engineers.

    As far as feature development, we are very careful in doing a lot of user research before we start to build anything. We are also very intentional about making sure the scope is reasonable by only building the features that are requested by users.

    What is the decision-making process that went into making all these decisions?

    The key decision-making process is realizing that we are a startup with limited resources, and our goal at this stage is to reach product-market fit as quickly as possible. Every decision we make is based on that premise. This means that there are a lot of optimization or scale decisions that we can't get to or that we need to offload. While these sorts of challenges can be technically challenging and fulfilling, it usually means it's better for us to offload the work to different services that will get you something working immediately.

    If you want to learn more, feel free to reach out to me on Slack. Would love to go in-depth about anything you find interesting!

    • 1
      Profile picture
      Software Engineer [E4] [OP]
      Aptos Labs
      2 months ago

      Thanks a lot, Charlie for the wonderful answer!
      When I started learning full-stack development, MERN stack was very popular. What's your take on using React and MongoDB vs using Next.js and Firebase?

      It seems the Next.js is useful here because most of the webpages and content on taro is static, and Next.js enables caching. For more dynamic content, let's say when building Facebook or LinkedIn, would React be a preferred choice?

      Firebase seems easy to work with for a prototype. But it seems pretty expensive. For example, their data transfer cost is $0.15/GB and Taro users stream a lot of videos. Is it possible to cache this content as well to minimize the cost? Their auth costs also seem expensive once you achieve a scale. At what scale, would you consider moving to an alternate database?