Skip to content
Anatoly Kulakov edited this page Feb 12, 2018 · 6 revisions

Обоснование необходимости серверной части

Семейству программных продуктов, реализуемых в рамках проектов DotNetRu, часто необходима серверная часть. Т.к. frontend проектов много и задачи у них разные, вполне вероятно, что речь в этом документе идёт не об одном решении, а о комплексе взаимосвязанных сервисов.

Интеграция с социальными сетями

Проблема

Изначально сообщества не хотели загонять своих прихожан в какую-то одну социальную сеть. Было очевидно, что неудобно будет всем. Это решение было верным и позволило нам дотянуться до наибольшего числа заинтересованных. Но минусом данного подхода стала необходимость поддерживать в синхронном состоянии все соц. сети. Сейчас это делается вручную и отнимает огромное количество времени у программных комитетов.

Предложение

Хочется автоматизировать рутинную работу, не требующую индивидуального подхода. Например давая анонс мероприятия, желательно чтобы он появился во всех соц. сетях. Тоже относится например к публикации итоговых материалов (фотографий, слайдов, видео-записей).

Сейчас используются:

Тонкости

  • Некоторые соц. сети требуют индивидуальной обработки фотографии к заметке (разные размеры).
  • Публикация в Твиттер'е ограничена по размеру и должна формироваться с учётом этой особенности.
  • Для разных сообществ существуют разные аккаунты в разных соц. сетях
  • Некоторые заметки необходимо "репостить" между Сообществами

Интеграция с интернет-сервисами

Проблема

Так как Сообщества стремятся максимально снизить стоимость существования, они обширно используются сторонние бесплатные сервисы. Работа с различными сайтами, форматами и связями требует большого количества времени и потребляет не мало памяти.

Предложение

Необходимо настроить интеграцию рабочего места программного комитета с используемыми сервисами.

Сейчас используются:

  • TimePad (анонсы)
  • Google Forms (формы обратной связи)
  • MailChimp (почтовая рассылка)
  • GitHub (хранилище, автоматизация, взаимодействие с другими разработчиками)
  • YouTube (видео)
  • Trello (ведение заявок на доклады)

Тонкости

  • Для разных сообществ существуют разные аккаунты в сервисах.

Управление Аудитом

Проблема

Сейчас Аудит редактируется методом исправления XML файлов. Это долго, скучно и чревато ошибками. Уже запланирован проект UI редактора на Ангуляре. Который должен упростить ситуацию. Именно Аудит является основным источником информации о Сообществах для всех последующих приложений.

Предложение

Необходимо предоставить удобный API для полного управления аудитом (чтение, добавление митапов, редактирование спикеров, фотографий и т.д.). Также нужно будет сделать автоматическую публикация анонсов в соц. сети на основании изменения Аудита.

Тонкости

  • Весь Аудит должен продолжать храниться в XML на GitHub
  • Должна быть возможность переиспользовать хранилище в сторонних продуктах. Поэтому, скорее всего, необходимо выделить отдельный проект абстрагирующийся хранилище (GitHub, XML). Так же он должен взять на себя ответственность за целостность данных на низком уровне (есть много правил валидации).

Обслуживание App

Проблема

Наше Xamarin приложение призвано донести всю базу Аудита до конечного пользователя в удобном виде. Сейчас оно работает без серверной части, но предпосылки для её появления в будущем уже вырисовываются.

Предложение

Необходимо в компактной форме предоставлять приложению информацию о наличии обновления Аудита. А так же формировать и предоставлять пакет с обновлением. Скорее всего реализация push-уведомлений тоже потребует наличие сервера.

Тонкости

  • Очень большое размытие по версиям. Необходимо будет поддерживать старые версии API.
Clone this wiki locally