LINUX.ORG.RU

Какую технологию выбрать для клиент-серверной штуки?

 , , ,


0

1

Приветики.

Есть потребность сделать диалог между сервером и мобильной штуковиной несколько более rich, чем тупой HTTP с «логи отдал - настройки забрал».

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

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

Технология™ должна уметь в кодогенерацию клиентской части при необходимости таковой; ручной разбор JSON'a хотелось бы оставить в 2k7.

На данный момент рассматриваю старый недобрый SOAP/Axis и OpenAPI/Swagger; один знакомый чел сказал, что в подобных условиях гонял данные через RabbitMQ, но я сильно подозреваю, что он курит что-то нездоровое, и не склонен воспринимать этот совет всерьёз.

Шо из вышеупомянутого и неупомянутого посоветуете использовать в моих условиях? Каковы плюсы, минусы и подводные камни в луже, в которую я сяду?

ЗЫ. Специальный вопрос для Забанься-Дебила, как для эксперта по ЛОРу: почему на мобильном Edge аватарки так жутко растянуло по высоте и как это исправить?

Обычный REST пользуй и мозг не парь себе, всем подходит, а ты прям такой уникальный что ли. OpenAPI нормальная тема. SOAP тебе не нужен.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

izzholtik ★★★
() автор топика
Ответ на: комментарий от izzholtik

Ну если выбор обусловлен чем-то, тогда ладно. Только дам один совет. Не используй никакие библиотеки. Тупо собирай XML-ку (ну XML-библиотеку, конечно, используй) руками и делай POST с нужными заголовками. И разбирай ответ. 90% боли от SOAP-а из-за упоротых библиотек. А когда ты тупо пердолишь XML туда-сюда, ну чуток скучного кода напишешь, но это не страшно, зато не будешь от упоротых библиотек страдать.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Я третий год пишу скучный код на Java SE с голым JAXB и выдумываю костыли к самописному протоколу, надоело :<

izzholtik ★★★
() автор топика
Ответ на: комментарий от Legioner

Алсо, да, раз уж ты тут .-.
Я подумываю на клиентскую часть тоже Liquibase натянуть, но оно по версиям и, соответственно, по состоянию БД пипец как разнится. Косяк меня-из-прошлого, ага. Что в этом случае лучше сделать, учитывая неинкрементальное обновление? Мя вижу три варианта - запуск самописного костыля, апдейтящего старые версии до «стартового» состояния, миграции с кондишнами, пересоздание БД и импорт в неё из существующей. Последний вариант выглядит наименее уродливым, но вызывает вопросы по поводу наличия свободного места..

izzholtik ★★★
() автор топика
Последнее исправление: izzholtik (всего исправлений: 1)
Ответ на: комментарий от izzholtik

Хз, тут я пока шишки особо не набивал, не берусь судить, что лучше.

Legioner ★★★★★
()

для плохой связи и маленьких устройств бери mqtt, он изначально для этого придумывался

EugeneBas ★★
()
  1. При чем тут rabbit mq? Это же брокер очереди для сервера, а ты говоришь про связь клиент/сервер. У тебя что в раббит клиент напрямую ходит?

  2. OpenAPI/Swagger это хорошо, но каким боком он в вопросе? swagger нужнен для того, что бы твои фронтендеры и другие коллеги могли без бутылки разобраться как работает твоя АПИ.

очень любят забираться в глухие подвалы, где связь прыгает между E и G

рассматриваю старый недобрый SOAP/Axis

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

Aswed ★★★★★
()

Соап хорош, но если связь совсем плохая то сообщения нужно делать поменьше, а значит грпц или трифт.

ya-betmen ★★★★★
()

административными мерами это не фиксится

да ну, сейчас каждое адекватное приложение при запуске проверяет наличие новой версии и в случае обнаружения таковой говорит: Извините, Ваша версия устарела, и нии..ёт.

ukr_unix_user ★★★★
()

сделать диалог между сервером и мобильной штуковиной несколько более rich, чем тупой HTTP

Наверное, всё-таки между мобильной штуковиной и сервером? И что это будет, приложение в браузере или как?

Если первое, то graphql.

vvn_black ★★★★★
()

хз что там за протокол обмена, но в качестве транспорта посоветую rsocket.

очень хорошо выживает на мобильных сетях.

olelookoe ★★☆
()
Ответ на: комментарий от Aswed

1, 2 - ты как будто пост не читал, а надёргал из него кейвордов :(
3 - экономия на спичках, которую полностью нивелирует gzip, и тоже мало касается темы поста.

izzholtik ★★★
() автор топика
Ответ на: комментарий от ukr_unix_user

нии..ёт

Очень бы не хотелось, чтобы приложуха внезапно кирпичилась на несколько часов, если интернет совсем плохой. 20 мегабайт через EDGE - довольно плохая история.

izzholtik ★★★
() автор топика
Ответ на: комментарий от vvn_black

всё-таки

ес. Мя просто AMQP'шкой в тот момент был упорот и в обратную сторону думал.

graphql

Сомневабельно. Мне скорее RPC надо, чем запросами данных манипулировать.

izzholtik ★★★
() автор топика
Ответ на: комментарий от izzholtik

Мне скорее RPC надо

Так и непонятно, это всё в браузере планируется или как. Заботы транспорта можно переложить на firebase, если нет религиозных предубеждений.

vvn_black ★★★★★
()
Ответ на: комментарий от izzholtik

на несколько часов, если интернет совсем плохой

современный человек очень редко оказывается в таких условиях, чаще мечтает о них.

ukr_unix_user ★★★★
()
Ответ на: комментарий от izzholtik

У SOAP есть киллер-фича - его с недавних пор нативно поддерживает 1С.

с недавних пор

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

ergo ★★★
()
Ответ на: комментарий от Legioner

. Тупо собирай XML-ку (ну XML-библиотеку, конечно, используй) руками и делай POST с нужными заголовками.

«… А потом чувак, который возьмётся за апгрейд твоего легаси-говна отрубит тебе руки», чего не договариваешь?

anonymous
()
Ответ на: комментарий от Shadow

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

izzholtik ★★★
() автор топика
Последнее исправление: izzholtik (всего исправлений: 2)

gRPC советовали?

anonymous
()

SOAP

Дрочево. Делай проще: web api на get и post запросах.

Тут советуют REST. Но та вещь, которую большинство людей называют «rest» - на самом деле не rest, а кастомное web api. Настоящий rest это тоже дрочево. Нуегонах.

ox55ff ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.