---
title: Mascot Architecture
tags: Templates, Talk
description: Presented on 28th Jan 2022
---

# Let's build, but how?

### A few questions for y'all! :brain:
- What is the Data Plane, what is the Control Plane?
- What is a [Platform](https://www.linkedin.com/pulse/platform-product-leadership-nitin-julka/), and why should we worry about this now?
- How would external developers consume our services, with externalization in mind
- Can users self-host Mascot, if they wish to?
- What are the major inefficiencies in our software development flow right now?

### Microservices :computer:
- [Design Patterns of Microservices](https://www.edureka.co/blog/microservices-design-patterns)
- Aggregator
- API Gateway
- Chained or Chain of Responsibility
- Asynchronous Messaging
- Database or Shared Data
- Event Sourcing
- Branch
- Command Query Responsibility Segregator
- Circuit Breaker
- Decomposition


- [WTF is BFF](https://microservices.io/patterns/apigateway.html)? Is it different from an API Gateway?

### What do we need? :handbag:
- High performance on the Client, we don't like chatty websites
- The client shouldn't worry about changes to the backend services
- Mascot as the core data layer shall function independently of the clients
- Mascot should be consumed by external third-party developers, build an Outside-In architecture
- We don't want to repeat the same code in all the services - we need DRY!
- What else?

---

****
---

### What do we have now? :smiley:

- Martini: Frontend for Signals!
- Mojito: Service that takes care of all client interactions on Signals + Stores details about signals + Runs CRON jobs
- Cosmo: Service that takes care of authentication + authorization
- mascot-core: Takes care of Fivetran ELT + Warehouse connection + Queries to Warehouses + Authentication via SecretKey
- mascot-dbt: Runs transformations on the connected warehouse

---

## Suggestions :bulb:

- API Gateway for each UI that we launch
- Each of these gateways use Cosmo for auth
- These gateways rely on Mascot for all warehouse-interfacing requests
- These gateways would rely on one specific service that would deal with the CRUD logic for the respective use case
- The brand new Mascot UI(Workbench for Growth Engineers) is a new UI, that gets a brand new backend API Gateway
- mascot-core is exposed as `api.mascot.software` with an API Key and Secret Key for developers that wish to build their own applications on the warehouse
- Miro: https://miro.com/app/board/uXjVOXKByMI=/


---

### Open Questions :thinking_face:

- How should the backend for Mascot Workbench be designed?
- Should it be just one service?
- Should it be broken down into multiple services:
- Everything related to Blocks and the Canvas
- Everything related to Templates created by the users
- Marketplace of templates(for later)
- Right now, mascot-core takes care of multiple use cases, and might slowly become a monolith in itself. When should it start breaking down into smaller services:
- Depends on how the usecases like Machine Learning/BI shape up
- Use cases right now:
- Interface with Fivetran
- Connecting to warehouses(selfhosted/Houseware's)
- Querying the warehouse
- Fetching/Creating Metrics
- Running on-the-fly transformations(?)
- Machine Learning Prediction Jobs
- Does Golang's hexagonal architecture help us build these individaul modules separately within the same service?
---

### Thank you! :sheep: