Программирование[10]

нахуй с докой из таверны

мне графкл не нравится
нету предсказуемости, это как-то неудобно когда вместо endpoint балом командуем структура самого запроса 

вот например сейчас задача есть аддон на мою ERP который принимает рандомный graphQL http request
мне надо было добавить поддержку pagenation

Например если делают квери на чтение таблицы клиентов, но не указывают какого конкретного (например для синхронизации сущностей в разных системах), то надо пройтись по всем page которые возвращаются в виде cursor/nextCursor. Получается запрос в цикле и мне надо менять всего одного значения в новом запросе cursor на основании ответа nextCursor.
Так вот это ебаная ссанина так как формат и структура graphQL запроса может кардинально отличаться, причем это не JSON или XML формат, тупо блять text. Вот как с этим говном работать? Регулярками? В тех же rest API это зачастую headers или хардкор структура(page всегда на одном месте в структуре)

 Ну я попросил переместить бекэендеров pagenation в headers для request/response - так они ответили для repsonse да(а нахуя мне, repsonse хотя бы в json формате), а для reqest эт плохо.. А я хз как по нормальному

в моей ERP даже нету механизма чтобы билдить эти graphQL request, просто блять работа с текстом
это везде так?)

А ну да, я понял почему это так больно. Мне приходит большой стринг graphql запроса с данными, без variables в JSON формате. Ну понятно, пойду кошмарить пацанов которые писали логику запросов в моей ERP...... пусть меняют все реквесты говна

графкл придумали долбоебы и юзают его долбоебы

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

и алгоритмическая стоимость доступа к информации сильно разнится

схуяли ради 10 минут работы на объявление модельки под конкретный случай надо ебаться потом остаток дней, что тебе может придти такой запрос, что база нахуй ляжет, и тебе надо его валидировать и ограничивать, а потом начинаются "ой у нас проблема с N+1, мы её отложенным выполнением через агрегатор закрываем" ебаный стыд.

Совсем уже кукухой поехали со своими носклами

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

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

это прямое противоречие со всем, что делается в программировании

ыыы

Drakonian написал 8 часов назад:

это не JSON или XML формат, тупо блять text

можно я открою маленькую тайну

json и хмл

это тоже тупо текст

...

в определенном формате

также как и graphql запрос

........

Drakonian написал 8 часов назад:

мне графкл не нравится
нету предсказуемости, это как-то неудобно когда вместо endpoint балом командуем структура самого запроса 

вот например сейчас задача есть аддон на мою ERP который принимает рандомный graphQL http request
мне надо было добавить поддержку pagenation

Например если делают квери на чтение таблицы клиентов, но не указывают какого конкретного (например для синхронизации сущностей в разных системах), то надо пройтись по всем page которые возвращаются в виде cursor/nextCursor. Получается запрос в цикле и мне надо менять всего одного значения в новом запросе cursor на основании ответа nextCursor.
Так вот это ебаная ссанина так как формат и структура graphQL запроса может кардинально отличаться, причем это не JSON или XML формат, тупо блять text. Вот как с этим говном работать? Регулярками? В тех же rest API это зачастую headers или хардкор структура(page всегда на одном месте в структуре)

 Ну я попросил переместить бекэендеров pagenation в headers для request/response - так они ответили для repsonse да(а нахуя мне, repsonse хотя бы в json формате), а для reqest эт плохо.. А я хз как по нормальному

в моей ERP даже нету механизма чтобы билдить эти graphQL request, просто блять работа с текстом
это везде так?)

А ну да, я понял почему это так больно. Мне приходит большой стринг graphql запроса с данными, без variables в JSON формате. Ну понятно, пойду кошмарить пацанов которые писали логику запросов в моей ERP...... пусть меняют все реквесты говна

ну во 1х графкл явно не для синхронизаций системы задумывались)

они же задумывались для фейсбучных UI запросов

если тебе нужно использовать UI апи для синхронизаций систем - то пресс Ф, не в графкл дело

соглашусь что рест под это чуть лучше подойдет. но и даже с ним проблема разграничения UI api и synchronuization api никуда не уйдет

Drakonian написал 7 часов назад:

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

soap это же худшее говно во вселенной родом из 2000-ных

Kant написал 8 часов назад:

графкл придумали долбоебы и юзают его долбоебы

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

и алгоритмическая стоимость доступа к информации сильно разнится

схуяли ради 10 минут работы на объявление модельки под конкретный случай надо ебаться потом остаток дней, что тебе может придти такой запрос, что база нахуй ляжет, и тебе надо его валидировать и ограничивать, а потом начинаются "ой у нас проблема с N+1, мы её отложенным выполнением через агрегатор закрываем" ебаный стыд.

 

Совсем уже кукухой поехали со своими носклами

 

ну опять же не проблема graphql что его юзают поверх sql

он же про графы 

запрос должен быть поверх графового хранилища

я ж говорю, долбоебы

Just.Doit написал 13 минут назад:

Drakonian написал 8 часов назад:

это не JSON или XML формат, тупо блять text

можно я открою маленькую тайну

json и хмл

это тоже тупо текст

...

в определенном формате

также как и graphql запрос

........

 

 

хоч я тебе открою большую тайну?

json и xml это тупо текст
а текст это тупо набор байтов........
двоичный код.....

а двоичный код это тупо ток
а ток это тупо..... електроны......

...........

..................

Kant написал 7 часов назад:

твой единственный эндпоинт должен уметь слишком много

какая разница ты разбиение абстракции сделаешь на уровне ендпоинта (url), на уровне хоста, или на уровне пейлоада запроса

ну тоесть условно

сущности: orders, users

можно сделать по микросервису на orders и на users, тогда хост будет кодировать сущность - http://orders:80/... http://users:80/...

можно сделать в одном приложении 2 ендпоинта http://myapp:80/orders/..., http://myapp:80/users/...

можно сделать в одном ендпоинте разные параметры запроса http://myapp:80/myapi/  | body: query_type = orders

какая разница где кодировать и чем это противоречит программированию? ))

ты когда по ssh на линукс ходишь, ты на 1 ендпоинт ходишь и выполняешь множество команд... ничего не смущает? )

Just.Doit написал 15 минут назад:

 

Drakonian написал 8 часов назад:

мне графкл не нравится
нету предсказуемости, это как-то неудобно когда вместо endpoint балом командуем структура самого запроса 

вот например сейчас задача есть аддон на мою ERP который принимает рандомный graphQL http request
мне надо было добавить поддержку pagenation

Например если делают квери на чтение таблицы клиентов, но не указывают какого конкретного (например для синхронизации сущностей в разных системах), то надо пройтись по всем page которые возвращаются в виде cursor/nextCursor. Получается запрос в цикле и мне надо менять всего одного значения в новом запросе cursor на основании ответа nextCursor.
Так вот это ебаная ссанина так как формат и структура graphQL запроса может кардинально отличаться, причем это не JSON или XML формат, тупо блять text. Вот как с этим говном работать? Регулярками? В тех же rest API это зачастую headers или хардкор структура(page всегда на одном месте в структуре)

 Ну я попросил переместить бекэендеров pagenation в headers для request/response - так они ответили для repsonse да(а нахуя мне, repsonse хотя бы в json формате), а для reqest эт плохо.. А я хз как по нормальному

в моей ERP даже нету механизма чтобы билдить эти graphQL request, просто блять работа с текстом
это везде так?)

А ну да, я понял почему это так больно. Мне приходит большой стринг graphql запроса с данными, без variables в JSON формате. Ну понятно, пойду кошмарить пацанов которые писали логику запросов в моей ERP...... пусть меняют все реквесты говна

ну во 1х графкл явно не для синхронизаций системы задумывались)

они же задумывались для фейсбучных UI запросов

если тебе нужно использовать UI апи для синхронизаций систем - то пресс Ф, не в графкл дело

соглашусь что рест под это чуть лучше подойдет. но и даже с ним проблема разграничения UI api и synchronuization api никуда не уйдет

 

А что поделать, если пацаны тут задевелопили приложуху с nosql, а поверх присобачили graphql

Drakonian написал 1 минуту назад:

а ток это тупо..... електроны......

ток это не электроны, если что)

Drakonian написал Только что:

Just.Doit написал 16 минут назад:

 

Drakonian написал 9 часов назад:

мне графкл не нравится
нету предсказуемости, это как-то неудобно когда вместо endpoint балом командуем структура самого запроса 

вот например сейчас задача есть аддон на мою ERP который принимает рандомный graphQL http request
мне надо было добавить поддержку pagenation

Например если делают квери на чтение таблицы клиентов, но не указывают какого конкретного (например для синхронизации сущностей в разных системах), то надо пройтись по всем page которые возвращаются в виде cursor/nextCursor. Получается запрос в цикле и мне надо менять всего одного значения в новом запросе cursor на основании ответа nextCursor.
Так вот это ебаная ссанина так как формат и структура graphQL запроса может кардинально отличаться, причем это не JSON или XML формат, тупо блять text. Вот как с этим говном работать? Регулярками? В тех же rest API это зачастую headers или хардкор структура(page всегда на одном месте в структуре)

 Ну я попросил переместить бекэендеров pagenation в headers для request/response - так они ответили для repsonse да(а нахуя мне, repsonse хотя бы в json формате), а для reqest эт плохо.. А я хз как по нормальному

в моей ERP даже нету механизма чтобы билдить эти graphQL request, просто блять работа с текстом
это везде так?)

А ну да, я понял почему это так больно. Мне приходит большой стринг graphql запроса с данными, без variables в JSON формате. Ну понятно, пойду кошмарить пацанов которые писали логику запросов в моей ERP...... пусть меняют все реквесты говна

ну во 1х графкл явно не для синхронизаций системы задумывались)

они же задумывались для фейсбучных UI запросов

если тебе нужно использовать UI апи для синхронизаций систем - то пресс Ф, не в графкл дело

соглашусь что рест под это чуть лучше подойдет. но и даже с ним проблема разграничения UI api и synchronuization api никуда не уйдет

 

А что поделать, если пацаны тут задевелопили приложуху с nosql, а поверх присобачили graphql

пусть делают отдельное апи для задачи интеграции

Just.Doit написал 2 минуты назад:

Drakonian написал 3 минуты назад:

а ток это тупо..... електроны......

ток это не электроны, если что)

ты хотел сказать "не только электроны"?

Just.Doit написал 1 минуту назад:

Kant написал 8 часов назад:

твой единственный эндпоинт должен уметь слишком много

какая разница ты разбиение абстракции сделаешь на уровне ендпоинта (url), на уровне хоста, или на уровне пейлоада запроса

ну тоесть условно

сущности: orders, users

можно сделать по микросервису на orders и на users, тогда хост будет кодировать сущность - http://orders:80/... http://users:80/...

можно сделать в одном приложении 2 ендпоинта http://myapp:80/orders/..., http://myapp:80/users/...

можно сделать в одном ендпоинте разные параметры запроса http://myapp:80/myapi/  | body: query_type = orders

какая разница где кодировать и чем это противоречит программированию? ))

ты когда по ssh на линукс ходишь, ты на 1 ендпоинт ходишь и выполняешь множество команд... ничего не смущает? )

я уже всё написал в том посте, что именно с этим не так

если для тебя буква S в солиде пустой звук, то дальше вопросы отпадают сами собой

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

не бывает случаев, когда тебе вот просто блять обосраться как надо уметь делать что угодно

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

причем тут ссх вообще не понятно, ссх делает ровно 1 задачу, пробрасывает текст команды на сервер и ответ тебе назад. Он не занимается исполнением команды.

согласен с пиздой

Drakonian написал Только что:

Just.Doit написал 3 минуты назад:

Drakonian написал 4 минуты назад:

а ток это тупо..... електроны......

ток это не электроны, если что)

ты хотел сказать "не только электроны"?

нет, я хотел сказать что ток это электромагнитный феномен и с электронами он связан только тем что в некоотрых средах (металлы) передача ЭМ энергии происходит при участии электронов. сами электроны энергию не переносят и током не являются

это примерно также как говорить что давление (в трубах и не только) это вода

Drakonian написал 1 минуту назад:

согласен с пиздой

а вот ща обидно было(

Kant написал 4 минуты назад:

Just.Doit написал 9 минут назад:

Kant написал 8 часов назад:

твой единственный эндпоинт должен уметь слишком много

какая разница ты разбиение абстракции сделаешь на уровне ендпоинта (url), на уровне хоста, или на уровне пейлоада запроса

ну тоесть условно

сущности: orders, users

можно сделать по микросервису на orders и на users, тогда хост будет кодировать сущность - http://orders:80/... http://users:80/...

можно сделать в одном приложении 2 ендпоинта http://myapp:80/orders/..., http://myapp:80/users/...

можно сделать в одном ендпоинте разные параметры запроса http://myapp:80/myapi/  | body: query_type = orders

какая разница где кодировать и чем это противоречит программированию? ))

ты когда по ssh на линукс ходишь, ты на 1 ендпоинт ходишь и выполняешь множество команд... ничего не смущает? )

 

 

причем тут ссх вообще не понятно, ссх делает ровно 1 задачу, пробрасывает текст команды на сервер и ответ тебе назад. Он не занимается исполнением команды.

также как graphql эндпоинт.... нет?

Drakonian написал 8 минут назад:

Just.Doit написал 10 минут назад:

Drakonian написал 12 минут назад:

а ток это тупо..... електроны......

ток это не электроны, если что)

ты хотел сказать "не только электроны"?

могу порекомендовать видос на тему