-
Notifications
You must be signed in to change notification settings - Fork 12
Server Proposal
Семейству программных продуктов, реализуемых в рамках проектов DotNetRu, часто необходима серверная часть. Т.к. frontend проектов много и задачи у них разные, вполне вероятно, что речь в этом документе идёт не об одном решении, а о комплексе взаимосвязанных сервисов.
Изначально сообщества не хотели загонять своих прихожан в какую-то одну социальную сеть. Было очевидно, что неудобно будет всем. Это решение было верным и позволило нам дотянуться до наибольшего числа заинтересованных. Но минусом данного подхода стала необходимость поддерживать в синхронном состоянии все соц. сети. Сейчас это делается вручную и отнимает огромное количество времени у программных комитетов.
Хочется автоматизировать рутинную работу, не требующую индивидуального подхода. Например давая анонс мероприятия, желательно чтобы он появился во всех соц. сетях. Тоже относится например к публикации итоговых материалов (фотографий, слайдов, видео-записей).
Сейчас используются:
- Некоторые соц. сети требуют индивидуальной обработки фотографии к заметке (разные размеры).
- Публикация в Твиттер'е ограничена по размеру и должна формироваться с учётом этой особенности.
- Для разных сообществ существуют разные аккаунты в разных соц. сетях
- Некоторые заметки необходимо "репостить" между Сообществами
Так как Сообщества стремятся максимально снизить стоимость существования, они обширно используются сторонние бесплатные сервисы. Работа с различными сайтами, форматами и связями требует большого количества времени и потребляет не мало памяти.
Необходимо настроить интеграцию рабочего места программного комитета с используемыми сервисами.
Сейчас используются:
- TimePad (анонсы)
- Google Forms (формы обратной связи)
- MailChimp (почтовая рассылка)
- GitHub (хранилище, автоматизация, взаимодействие с другими разработчиками)
- YouTube (видео)
- Trello (ведение заявок на доклады)
- Speaker Deck (хранение слайдов)
- Для разных сообществ существуют разные аккаунты в сервисах.
Сейчас Аудит редактируется методом исправления XML файлов. Это долго, скучно и чревато ошибками. Необходим высокоуровневый визуальный редактор (у нас уже есть несколько попыток: WebUI, DevActivator), который должен упростить ситуацию. Именно Аудит является основным источником информации о Сообществах для всех последующих приложений.
Необходимо предоставить удобный API для полного управления аудитом (чтение, добавление митапов, редактирование спикеров, фотографий и т.д.). Также нужно будет сделать автоматическую публикация анонсов в соц. сети на основании изменения Аудита.
- Весь Аудит должен продолжать храниться в XML на GitHub
- Должна быть возможность переиспользовать хранилище в сторонних продуктах. Поэтому, скорее всего, необходимо выделить отдельный проект абстрагирующийся хранилище (GitHub, XML). Так же он должен взять на себя ответственность за целостность данных на низком уровне (есть много правил валидации).
С появлением Blazor WebAssembly, описываемых задач можно добиться и без централизованного backend сервера. Возможно стоит загружать полноценное .NET приложение в браузер к лидерам сообществ и позволить им редактировать Аудит и публиковать анонсы. Плюсы данного подхода:
- цикл полной разработки остаётся в рамках .NET, ибо Blazor обеспечивает UI
- для хостинга WebAssembly достаточно бесплатного GitHub Pages, больше не нужно никаких Docker'ов и Azure'ов