Tech stack, conventions, environments

Языки

Чтобы иметь единообразный опыт работы с репозиториями кода и из-за ограничений команд, мы хотим ограничить возможный технологический стек (по крайней мере, на данный момент) этими языками:

  • Javascript (Машинописный текст)
    • React/TSX для фронтенда
    • NodeJS (для сервисов BE с низкой нагрузкой)
  • Go (для высоконагруженных сервисов BE)
    • C/C++ - для встраиваемых устройств
  • Питон
    • для моделей машинного обучения и анализа данных. Бывший. используя
    • для ранних прототипов сервиса, где важна простота/скорость интеграции, можно скопировать. Бывший. обработка видео с помощью opencv

Хранилище

Для баз данных и постоянства мы используем

  • MySQL ← возможно, в будущем мы могли бы перейти на Postgres, но atm давайте придерживаться этого
  • Redis ← для кеширования и публикации субтитров
  • SQLLite ← для периферийных устройств, если что-то нужно хранить более длительное время, но нет желания возиться с выделенным сервисом

(Облако) API ограничения

Для общедоступного API мы полагаемся на graphql Federation, поэтому, если вы создаете микросервис, убедитесь, что язык и платформа поддерживают это.

Федерация GraphQL позволяет нам объявлять схему в строго типизированном формате, сохраняя при этом независимость сервисов.

Если вас беспокоит стандартизация вариантов схемы GraphQL, таких как стандарт нумерации страниц или шаблон глобального идентификатора, тогда сначала используйте простую нумерацию страниц, а затем усложните ее. Для UUID

Внешний интерфейс

Мы используем urql, потому что

  • мы не используем apollo-client, потому что он большой по размеру файла
  • мы не используем Relay, потому что он очень придирчив к типам, делает запросы слишком динамичными с его фрагментами

Граничные устройства OS

Но вас это не должно сильно волновать, поскольку сервис следует писать как Docker container.

Периферийные устройства API

Это еще не до конца ясно.

  • Используйте Protobuf & GRPC. Главным образом потому, что вы не занимаетесь обслуживанием внешних клиентов, а эффективность является наиболее важным вопросом.
  • Используйте REST API /graphql, если сервис является гибридным. Например, если это модель, которая работает как на периферии, так и в облаке.