Привет, это снова Егор Гаврилов, и сегодня я расскажу о том, как Java и Spring Framework позволит написать архитектурно сложные приложения даже для таких сетей, как Фидонет.

В качестве примера мы возьмём такой проект, как NodehistJ - сервис для работы с историческими нодлистами (списками узлов данной сети). Это приложение состоит из нескольких независимых сервисов, каждая из которых тянет свою БД, но использует общее S3-хранилище, и общий экземпляр Kafka для обмена информацией о новых нодлистах.

Первый подход - Spring Data

Spring Data - это группа различных средств по удобной работе с JPA, NoSQL, и даже с JDBC.

Даже в контексте Фидонета мы используем разные СУБД для разных частей своих проектов. Для кэша мы используем Redis, для бигдаты (коим и являются нодлисты) мы используем Apache Cassandra, для более "приземлённых" данных (база сообщений, а также настройки узла и их пользователей - это касается другого моего проекта, связанного с Фидо) есть PostgreSQL.

Всё это объединяет одна технология - Spring Data, предоставляющий удобный интерфейс по работе с разными типами СУБД.

Spring Cache - кэшируем с лёгкостью

Spring Cache предоставляет слой для работы с кэшем. Поддерживается как memory-based кэш со стороны самого Спринга, так и такие технологии, как Redis. Это позволяет снизить нагрузку на СУБД, а также на само приложение, особенно при работе с такими большими данными, как те же нодлисты.

Spring Kafka - обмен сообщениями между разными сервисами

Обмен сообщениями - это важная часть любого набора микросервисов. Для этого существует проект Spring Kafka - набор инструментов для работы с Apache Kafka. Это и позволяет делать сложные приложения с микросервисной архитектурой - даже для Фидонета. В контексте NodehistJ - это как раз обмен информацией о новых нодлистах между даунлоадером, и остальными сервисами.

Spring Web - доставляем контент в удобном формате до клиента, + размышления о "Фидонете будущего"

Spring Web позволяет доставлять информацию до клиентской части приложения с помощью таких стандартизированных технологий, как HTTP и JSON, что позволяет NodehistJ доставлять нодлисты в более удобном формате для клиентов, а в будущем планируется выпуск мной полноценного FTN-сервера, позволяющий доставлять сообщения до конечных юзеров, а также между совместимыми узлами по этим же протоколам, что должно обеспечивать удобный и безопасный транспорт сообщений в рамках "Фидонета будущего", без использования нестандартных протоколов, и с полной интегрцией с Интернетом. При этом новый протокол будет иметь режим обратной совместимости с "классическим Фидонетом", обеспечивающий совместимость с DOS-кодировками, путём ограничения использования несовместимых символов Юникода, а также устанавливающие дополнительные ограничения по количеству информации, требуемые спецификациями "классического Фидонета".

Предполагается, что "Фидонет будущего" будет жить по тем же правилам, что и "классическое Фидо", также соблюдать POLICY4, иметь такую же адресацию, и так далее. "Фидонет будущего" - это, в первую очередь, именно о технологическом прорыве в области legacy-сетей, а не о полном отказе от прежней культуры и правил поведения в сети. "Фидонет будущего" будет развиваться параллельно с "классическим", и это будет примерно тоже самое, как постепенный переход с модемной связи на Binkp, только с постепенным отказом от большинства старых технических ограничений, которые тянутся с самого появления сети в 1984 году.

Это примерно тоже самое, как переход с Win16 на Win32, или выпуск Windows Vista, которая стала следующей этапом эволюции Windows, представив UAC, поддержку 64-бит, и многое другое.

Вместо итогов

Фидонет должен двигаться вперёд. Сеть должна сохранять свою идентичность - но при этом технические ограничения мешают двигать сеть вперёд. Именно поэтому мой проект FidoJ должна когда-нибудь в будущем приблизить нас к "Фидонету будущего", создав референсную реализацию данной идеи.