Архитектура клиент-серверного приложения

Причем тут буст, где тут хттп глубже вебчика, что с чем связано?

Всё очень просто. В чём проблема хттп? В том, что это изначально мусорное дерьмо, которое не имеет смысла к существованию. Ладно бы это можно был объяснить тем, что «это просто для открытия страничек в вебе, просто пересылка текста», но нет. Это не так. Это типичный оверинжиниринг, когда за работу берутся ламерки, которые не решают задачу, а говорят с голосами в голове.

Инженерно имлементация из буста(либо сверху буста) следует тем же традициям. Всё пропитано базовыми идеями, которые и родили хттп.

Хттп это способ «рассказать о себе» в сети

Чего? О каком себе? Хттп не может тебе ничего рассказать, успокойся. Ты опять всё перепутал.

. С кучей фич уровня «отправить в окно 8», «сказать, что сегодня мы не работаем»

Шизофрения.

и прочий балансинг с проксированием.

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

И все это на спец.софте с конфигами.

И? Причём тут хттп? К хттп это не имеет никакого отношения, ведь софт был бы под что угодно.

Если не хттп, то придется лепить хендшейки

Чего? У тебя явно голоса в голове.

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

Опять какая-то херня невероятных масштабов. Всё это работает и для хттп. Какую версию хттп будешь юзать?

К тому же, с этим нет проблем. Хттп это транспортный уровень, для которого вообще ничего не нужно - он уже есть. Просто когда-то кое кто не осилил нормальное кодирование, бинарь и родил это. Вот и вся история.

Ирл нормальный сервер и клиент отдают заголовков не более чем на один мту

Опять голоса в голове. К тому же, никакой нормальный протокол ничего подобного не передаёт.

К тому же, что ты начинаешь плыть на нормальный клиент/серверы, которые реализуют совершенно другие принципы, которые к хттп не имеют никакого отношения. Они там вопреки хттп, а не благодаря.

дальше идет тупо контент или дуплекс.

Опять шизофазия. Никакого дуплекса в хттп нет. Ты очередной эксперт, где-то где-то услышал про keep-alive и давай генерировать какую-то херню, даже не понимая что это и зачем.

Че ты привязался к каким-то тормозам, которых даже нет?

Опять голоса. Ты хочешь поиграть в игру «давай запилим и побенчим»? Я не против.

Не смотри на этот их сракет.ио да и все.

Опять какую-то херню пишешь. Опять где-то что-то услышал и начинаешь кидаться. Причём тут какой-то сракет.ио, почему я должен/не должен на него смотреть?

«У клиентов браузер на телефоне или компе». Ирл свои условия и требования ты ставишь только в своих фантазиях, вот и вся история. А если ты про митрилы или целлжсы (тебя сразу фиг поймешь), то они оверкилл для прошлых задач, потому и не трогал.

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

Пойми простую вещь. Допустим я возьму твою какую-то реализацию или сам запилю каким-то чудом. И в синтетике она покажет какие-то приросты и все скажут ооо. Но внезапно, в работе, это будет какой-то микроприрост, потому что линейные микробенчи не говорят о производительности нихрена. Я потрачу дохоена времени+денег на запил/инструментацию/скилование, а в итоге пук 3%, который и так не был нужен на старте. Большой процент проектов дохнет стратегически еще до первых проблем с софтом/железом, а те, что выживают, редко требуют именно ускорения. На практике, сложная задача по ускорению чего-то на порядок стояла лишь раза два-три за весь период в скоро уже 20 лет, и твои приросты в 200% там ничего не решали.

Если меряться, то работами, братишка, а не бенчами, но я по ряду причин не буду их тут описывать.

socket.io самая распросраненная и ущербная реализация транспорта жусонов между хостами. Если не слышал о ней, что ты вообще слышал об оверинжиниринге и тормозах.

Все посоны. Расходимся. Вот решение моей проблемы https://wwww.realm.io/

«Server not found», да, кардинальное решение.

WWWW - случайно вписал

https://www.realm.io/

Ну ты ведь для себя написал/нашел какой-то делающий то, что тебе нужно пример. Или ты выбрал по описанию?

Показал бы посонам в чём суть твоего решения.

https://www.realm.io/

Реалм это платформа и база данных для создания offline-first мобильных приложений. Мысль в том что-бы делать приложения не зависящие от подключения к интернету и обновлять данные при подключении.

В основе лежит объектно ориентированная база данных которая позволяет реактивно, в режиме реального времени обновлять данные на всех устройствах. При этом если нет интернета, сервис полностью берет на себя проблему по сохранению данных локально до следующего подключения.

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

Подсказали данный сайт, друзья. Разработчики криптобиржи.

2000$ в год за селфхостед? У тебя тоже криптобиржа?

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

Ну, если есть возможность решить проблему за счёт пользователей, то почему бы и нет. А так, кмк, 2k$ это как раз цена для «своего» частного решения по синхронизации данных приложения.

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

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

Я всё это прочитал и не об этом спрашивал.

Смысл моего вопроса заключается в том, что определения решения за решение(для данного конкретного случая) нужно как минимум реализовать на нём хоть что-то выражающее основные требования твоего случая.

Как минимум я вижу множество возможных вопросов, которые у меня возникли бы, если я захотел применить это.

Допустим, у меня есть бд. Мне нужно её(её инстансы) синхронизировать. Хорошо, но у меня есть доверенные и недоверенные «инстансы» бд. Я должен мочь валидировать все обновления, которые присылает юзер. Могу ли я? Как я буду это делать?

Этот же вопрос относится и к - как нам добиться консистентности данных? Мы не можем быть уверены, что в данный момент мы работаем с актуальными данными.

У всех этих мусорных БД очень плохо с количественными величинами, которые семантически нельзя перезаписывать. Есть твои друзья, разработчики криптобиржи, у них есть бабки. Бабки такая же величина. Их нельзя удалять, их нельзя забирать - их можно только перемещать. Как минимум семантическим их можно только уменьшать/увеличивать.

Как ты это реализуешь? Оно может в какие-нибудь инкременты/декременты? Хотя даже их мало для безопасной имплементации, ведь это всё равно нарушает базовую семантику.

Если у тебя есть инкременты/декременты, ты можешь закостылить в рамках транзакции перемещение, но тут опять жопа. Ты не сможешь(не должен) мочь изменять данные через db-api, только через кастомный трансфер.

Опять же, каким образом оно может решать конфликты? В рамках колхозной БД вообще такого понятия нет. Конфликты они семантические, они вне логики БД( у которой вообще логики нет). Вся эта логика реализуется сверху.

И теперь мы возвращаемся к началу. Это логика не может отрабатываться на уровне недоверенного инстанса. И привет - ты всё сломал. Как это вообще должно работать в рамках их описания - мне неведомо.

Использую технологии nodeJS + vueJS

Когда ж вы, ушлепки, посдыхаете-то все? Додумался, жабоскрипт на сервак...

Когда Вы общаться вежливо научитесь и на нуль делить

Вопросы естественно возникли и я прочел всю доступную на сайте информацию по работе платформы, прежде чем сделать вывод что она мне подходит. На сайте есть несколько pdf файлов с достаточно развернутой информацией по её работе.

Опять же не утверждаю что это панацея, но на данный момент единственный прямой путь к законченному приложению с уверенностью его стабильной работы. Тратить еще несколько месяцев на создание собственного решения для offline-first приложения, я совершенного не готов.

Конечно некоторый скепсис все еще остается, но между риском довериться профессионалам в распределенных системах и написать свой костыль выбираю меньшее из зол...

На счет самой БД вы пожалуй предвзято отнеслись. 2 миллиарда устройств на ней работает если верить разработчикам. Возможно мы пользуемся приложениями разработанными с помощью этой платформы и не знаем об этом...

В ближайшие несколько дней я начну тестировать платформу и опишу тут свои впечатления. Как уже говорил скепсис все еще остается и для меня это в некоторой степени риск.