Артем Воронов

Не переусложняй:
1. Маленький проект, быстрый прототип - можешь смело держать все в одном проекте и не париться.
2. Долгоживущий проект с несколькими микросервисами, сложной бизнес логикой и т.п. - выделяй микросервисы в отдельные проекты, фронт держи отдельно.

Есть как минимум два подхода к решению этой проблемы:
- Посмотреть на чем сделаны аналогичные продукты, например Plex https://himalayas.app/companies/plex/tech-stack
- Делать на чем умеешь и по мере роста продукта заменять технологии. Исходя из формулировки вопроса, речь идет о pet проекте. Если так, то не стоит тратить дни на поиск идеального решения, надо просто начать делать. В ходе реализации придет понимание того, что действительно нужно.

Когда нанимаю себе бизнес аналитиков, смотрю следующие моменты в порядке важности:
- аналитические способности. Какие человек задает вопросы перед тем как начать работать над задачей, как подходит к выбору источников информации, как выстраивает логику решений и оценивает стоимость реализации
- софт скилз. Насколько хорошо человек умеет общаться и выстраивать отношения как со стейкхолдерами, так и с другими командами и разработчиками.
- системность в ведении документации и написание user stories. По моему опыту несистематичный аналитик увеличивает расходы на реализацию проектов временами на 50-100%, в особо запущенных случаях на 300%+
- понимание доменной области. Это наименее важный пункт, нормальные аналитик за 3-6 месяцев может разобраться даже в самых специфичных доменах.

Не смотрю на:
- курсы и образование, вообще ни о чем не говорят
- формальную сертификацию. Работал с людьми прошедшими сертификацию IIBA, которым приходилось объяснять базовые вещи
- технические скиллы. Даже самый слабый аналитик из тех с кем работал, за неделю освоил основы SQL и начал самостоятельно забирать данные для анализа. Сейчас при помощи ChatGPT проще простого подтягивать технические навыки

Любой современный треккер позволяет настроить частоту передачи и отправлять данные в API.
По большему счету для обычных нужд подходит любой треккер и частота передачи раз в 1-10 минут.
Если нужно еще мониторить показания топливных датчиков и дополнительной телеметрии надо брать что-то подороже.
Ну если задача стоит трекать спортивные мероприятия, необходимо подбирать специфичные профессиональные датчики.

Звучит как задача для Elastic (хранение логов) + Kibana для визуализации.

Сейчас работаю над аналогичной задачей:
- сотни источников данных, на разных языках и в разных региональных форматах
- данные фрагментированы, разные атрибуты одной и той же записи приходят из разных источников
- встречаются опечатки и мусор в данных

Что попробовали, но работает не очень:
- собственный DSL. Слишком дорого в поддержке, онбоардинг разработчиков превращается в ад.
- Использование шаблонов и маппингов специфичных для каждого истончика с помощью специфичного софта типа Xceptor. Опять таки дорого в поддержке и недостаточно гибко.

Что работает хорошо:
- Разделение процесса на этапы, все по классике Data Science: очистка данных от мусора, стандартизация форматов и т.п. Это позволяет не дублировать одну и ту же логику в отдельном обработчике для каждого источника, а консолидировать правила в одном месте.
- Elastic для перевода, синонимов и обработки опечаток
- Кросс проверки с дополнительными источниками данных, где это возможно

Notion как алтернатива Obsidian. Ультра просто и удобно.

Я собрал 3 подобных сервиса, как для Glonass/GPS, так и для AIS. В текущем решении 180 000 единиц транспорта отслеживается. Вот несколько базовых моментов из опыта:
1. Приборы отправляют данные на сервер сами, а не наоборот. Твоя задача принимать и быстро сохранять данные в бд. В какой - не важно. У меня хорошо работает связка из реляционной бд для оперативных данных типа текущего положения, nosql для архива.
2. Протоколов у трекеров огромный зоопарк, у каждого производителя свой. Не привязывай свою реализацию к конкретному протоколу. Сделай общий API для сохранения данных в базу, а затем уже подключай протоколы по мере необходимости.
3. Если тебе нужен геофенсинг, сразу закладывай event-driven архитектуру. Опять таки не важно какой ты возможешь брокер сообщений.
Все остальное вторично. Для отображения данных хоть на любом low-code забирай данные напрямую из оперативной базы и отображай на карте.

решал подобные задачи связкой TeamCity + Jira + Confluence: При деплое на Prod TeamCity подтягивала список заплоенных stories из GIT. Далее небольшой скрипт формировал страницу в Confluence, подтягивая детали stories из Jira. Завершалось это все сообщение в Slack c ссылкой на полученную страницу.
Это требует договоренностей с командой разработки, например, user story Id должно присутствовать в описани коммита.

Для получения данных об ограничении скорости не нужно отдельное устройство.
Если уже подключены как-то к круиз контролю, почему бы не получать текущие координаты от бортой системой навигации? Полученные коордианты и надо испольовать для запроса скоростных ограничений. Не стоит также ничего конвертировать в текстовый формат. Вместо это надо дергать API специализированных сервесов, например Google Roads - Speed limits. Наверняка аналогичные API есть у Яндекса и 2ГИС.

Для таких проектов не надо тратиться на разработку. Нет разработчика - нет проблем. Так же нет смысла на старте вкладывать в дизайн, можно просто купить готовую тему.
Вместо WP, лучше взять Ghost или Gatsby. В них нет стольких дыр сколько в WP и опять таки не требуются дополнительные знания.

В таких случаях хорошо сработает связка из NoSQL + GraphQL.
NoSQL даст возможность использовать одну и туже коллекцию для всех страховых, то есть сможете легко строить аналитику без 100500 join
GraphQL позволит гибко настраивать payload для внешних API

Наверняка вы уже трекаете активность пользователй в приложении. Если юзер не активен в течение N дней\месяцев, помечайте его как удаленный\замороженный\etc.
Заодно можно пуш кинуть ему от системы, чтобы попробовать активировать опять.

Это вам в Airtable надо, там есть контроль доступа на уровне таблицы, листа или view.

Боюсь что ты решаешь задачу с не того конца.
Курс ЦБРФ может быть один, но реальный курс зависит от банка и способа оплаты. Разница может доходить до 10%. Если включить случаи double-conversion, то ошибка может быть еще больше.

Приходилось решать подобные задачи, когда простейшим случаем была покупка контента за AED, оплата его кэшем в EUR, с полседующей перепродажей через AmericanExpress в USD. Сумма с точностью до цента получается только постфактум. И далеко не всегда платежная система дает тебе полную раскладку по комиссиям и курсам.