RFC: Allow adding more services to chatbot

[punkupoz]

RFC

Summary: Allow adding more services to chatbot
Created: 30/7/2021
Owner: Bao Nguyen [email protected]
Approvers: Phuong Bui, Trung Ly, Sam Huynh, Cuong Do
Status: In Review

Background

The chatbot is currently being written in TypeScript. To allows adding more functionality to the bot, we should allow writing services using other languages.

1. Architecture

1. Gateway
   The Gateway will be the entry point for the bot, when receiving messages from Discord, Gateway should process and send messages to Event Bridge.
2. Event Bridge
   The main Event Bus, EB will receive messages from Gateway and route the messages to Microservices accordingly.
3. Microservices
   Each microservice will handle it's own logic and database. Microservices will send responses to Discord if required.

2. API Interface

RESTful APIs

• MUST accept and response with JSON
• MUST make use of HTTP Verbs instead of putting verbs in path
• MUST use common HTTP Status codes for errors
• MUST include Swagger for OpenAPI specification.

3. Code quality and Documentation.

• MUST Provide Code of Conduct to maintain code consistency and quality
• MUST have integration test
• SHOULD maintain unit tests coverage

[hp0210]

Anh chưa rõ lắm phần Cognito, permission ở đây cần những gì? Có cần phải cognito và oauth2 ko?
Architecture ntn có phải là gateway phải call api của các service kia ko?

[punkupoz]

Em cũng nghĩ nhiều phần Cognito.
Có 1 hướng nghĩ là: Nếu mình có thể để con gateway ở trong private VPC, thì những con lambda functions kia có thể xem cái Gateway đó là trusted client. Vấn đề như thế dễ làm rắc rối về infrastructure của con Gateway.

Việc làm OAuth2 có những lợi ích là:

1. Nó tách ra được hoàn toàn service đó khỏi con Gateway, có nghĩa là sau này nếu mình không muốn dùng con gateway đó nữa mình hoàn toàn có thể giao permission cho một con mới dễ dàng (nó chỉ là api).
2. Nếu mình có extends ra nữa cho cái service đó. Ở đây em ví dụ cái Job board, mình có thể cho end users dùng PKCE, trong khi Gateway vẫn có thể dùng client_credentials.
3. Không cần phải maintain SSH keys các kiểu, em cảm thấy implement như thế này nhẹ nhàng hơn.

API Gateway là integration cho mấy cái lambdas. Có thể invoke lambdas trực tiếp nhưng e nghĩ nếu tách ra thành REST api thì nó sẽ dễ decouple cái gateway ra hơn

[punkupoz]

Architecture đã update và không cần Auth nữa, cảm ơn anh 👍

[dohaicuong]

About my suggestion on using GraphQL Federation yesterday, as we will have many services(bots), each service will have it own data/database that they managed on their own. Soon enough we will end up with some services that need to use data of other services.

There are several ways to achieve that

• Service call other services' database.
• Service expose some set of api and let other service to consume those.
• Service expose a graphql federation and let other service consume the one graph.

[punkupoz]

Good suggestion, but not in scope of this request.

[punkupoz]

Tasks to be completed.

1. Create a monorepo to maintain the services
2. Create Event Bus (Event Bridge)
3. Emit - command events to Event Bridge from Gateway
4. Pattern matching for events to be sent to Event Bridge (follows 3)

[punkupoz]

Notes:

1. The new monorepo will only contains the added services. Gateway will stay in this repo.
2. EventBridge rules infrastructure will be created by the added services subdirectories infrastructure
3. EventBridge will be created in the vait-caas repo