Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/ark2016/tehnopark-vk-system-design

some system design homework
https://github.com/ark2016/tehnopark-vk-system-design

bmstu database swagger system-design technopark vk

Last synced: 2 days ago
JSON representation

some system design homework

Awesome Lists containing this project

README

        

# Tehnopark-VK-system-design

## Задание: Документирование API Steam с помощью Swagger

### Цель:

* Изучить API веб-сайта Steam.
* Применить знания проектирования и документирования API с помощью Swagger.
* Практически исследовать и документировать реальный API.

### Задание 4.1: Документация существующего API

1. **Выбор разделов:**
* Выберите **два** раздела сайта Steam, **не рассмотренных** вашей командой в Задании 1.
* В разделах должен быть как минимум **один** комплекс CRUD-операций (Create, Read, Update, Delete), а не просто один endpoint.

2. **Исследование API:**
* Проанализируйте запросы и ответы в выбранных разделах. Используйте веб-версию сайта и консоль разработчика для анализа сетевых запросов.
* Определите необходимые авторизационные данные (ключи доступа, токены), если таковые требуются.
* Выявите связи выбранных разделов с другими разделами и данными сайта.

3. **Документирование API в Swagger:**
* **Опишите структуры данных:** Создайте модели данных, используемые в API выбранных разделов.
* **Создайте endpoints:** Опишите endpoints для запросов, выявленных в процессе исследования. Укажите:
* Пути к endpoints.
* HTTP-методы (GET, POST, PUT, DELETE).
* Необходимые параметры (в пути, запросе, теле).
* Ожидаемые ответы (коды состояния, структуры данных).
* **Добавьте описания:** Опишите назначение каждого endpoint, возвращаемую информацию и возможные операции.
* **Выявите проблемы и предложите улучшения:** Проанализируйте API с точки зрения удобства использования, полноты, безопасности. Предложите улучшения.
* **Создайте Swagger-файл:** Сформируйте Swagger-файл, содержащий:
* Описания структур данных.
* Коды ошибок.
* Служебные заголовки.
* Входящие и исходящие параметры endpoints.

### Задание 4.2: Документация нового/измененного API

1. **Выбор функциональности:**
* Из Задания 2 выберите функциональность, **не рассмотренную** вашей командой, для которой требуется изменение/расширение существующего или создание нового API.
* Если такой функциональности нет, придумайте её.

2. **Документирование API в Swagger:**
* **Расширение функциональности:**
* Опишите изменения в API в формате Swagger, аналогично Заданию 4.1.
* **Четко выделите изменения:** Опишите разницу между старым и новым API.

* **Новая функциональность:**
* Опишите новый API в формате Swagger, аналогично Заданию 4.1.

**Важно:** Документация должна быть понятна новому разработчику и позволять ему легко разобраться в изменениях API. Рекомендуется создать два Swagger-файла (старый и новый) для удобства сравнения.

### Ключевые моменты:

* Документация должна быть ориентирована на практическое использование, например, для написания frontend-части сайта.
* Проведите кросс-ревью документации внутри команды.
## Задание: Проектирование структуры базы данных для API Steam

### Цель:

* Спроектировать структуру базы данных (БД) для выбранных разделов API Steam.
* Определить тип БД и обосновать свой выбор.
* Оценить объем данных и потенциальные узкие места производительности.
* Проанализировать необходимость кеширования данных.

### Задание 5.1: Проектирование БД для существующего API

**Для каждого из двух разделов API, выбранных в Задании 4.1:**

1. **Анализ зависимостей:** Определите, от каких данных зависят выбранные разделы API.

2. **Проектирование структуры БД:**
* Смоделируйте структуру БД, которая будет полной и способной обслуживать любые запросы данных по выбранному разделу API.
* Для **реляционных БД:**
* Приведите схему БД, соблюдая как минимум 3 нормальную форму (3НФ).
* Укажите типы данных для каждого поля.
* Определите первичные и внешние ключи.
* Для **нереляционных БД:**
* Опишите, какие сущности (документы, объекты) будут храниться в БД.
* Укажите структуру и типы данных для каждого поля.
* Опишите связи между сущностями.

3. **Выбор типа БД:**
* Выберите тип БД (реляционная, документоориентированная, графовая и т.д.).
* Обоснуйте свой выбор, учитывая:
* Структуру данных.
* Типы запросов к данным.
* Требования к производительности.
* Масштабируемость.

4. **Оценка объема данных:**
* Оцените объем данных в БД, исходя из 1 000 000 пользователей.
* Рассчитайте примерный размер данных на диске.

5. **Анализ производительности:**
* Выявите потенциальные узкие места производительности (медленные запросы).
* Предложите решения для оптимизации запросов (индексы, денормализация).

6. **Анализ кеширования:**
* Определите, нужно ли кешировать данные для повышения производительности.
* Если кеширование необходимо:
* Укажите, какие данные будут кешироваться.
* Опишите сценарии заполнения кеша.
* Выберите подходящий механизм кеширования.

### Задание 5.2: Изменение схемы БД для нового/измененного API

1. **Проектирование схемы данных:**
* Нарисуйте схемы данных для нового/измененного API, аналогично Заданию 5.1.

2. **Визуализация изменений:**
* **Четко выделите изменения** в схеме данных, связанные с добавлением/расширением функциональности. Используйте цветовое выделение или отдельные схемы для старой и новой версии БД.

### Ключевые моменты:

* Схемы данных должны быть понятны новому разработчику и позволять ему легко разобраться в структуре БД.
* Проведите кросс-ревью документации внутри команды.

### Отчетность:

* Отчитывайтесь о проделанной работе два раза в неделю.
* Задание будет проверяться на РК-2.