Перейти к публикации
  • Сейчас на странице   Всего пользователей: 0   (0 пользователей, 0 гостей)

Rooster

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

Перепись  

313 пользователей проголосовало

У вас нет прав на голосование в этом опросе, или на просмотр результатов опроса. Пожалуйста, войдите или зарегистрируйтесь для голосования в опросе.

Рекомендованные сообщения

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

CriErr понравилось это

Поделиться сообщением


Ссылка на сообщение

мне графкл не нравится
нету предсказуемости, это как-то неудобно когда вместо 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, мы её отложенным выполнением через агрегатор закрываем" ебаный стыд.

 

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

 

DeadMage, nobodies, Drakonian и 1 другому понравилось это

Торжество разума в том, чтобы уживаться с теми, у кого этого разума нет. Вольтер.
Чтобы хорошо высыпаться, нужно спать 8 часов в день. И еще столько же ночью.

Поделиться сообщением


Ссылка на сообщение

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

Поделиться сообщением


Ссылка на сообщение

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

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


Торжество разума в том, чтобы уживаться с теми, у кого этого разума нет. Вольтер.
Чтобы хорошо высыпаться, нужно спать 8 часов в день. И еще столько же ночью.

Поделиться сообщением


Ссылка на сообщение
(изменено)
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 никуда не уйдет


Изменено пользователем Just.Doit

 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение
Drakonian написал 7 часов назад:

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

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

Поделиться сообщением


Ссылка на сообщение
Kant написал 8 часов назад:

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

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

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

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

 

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

 

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

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

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

nobodies понравилось это

 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение

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

GoldRobot понравилось это

Торжество разума в том, чтобы уживаться с теми, у кого этого разума нет. Вольтер.
Чтобы хорошо высыпаться, нужно спать 8 часов в день. И еще столько же ночью.

Поделиться сообщением


Ссылка на сообщение
Just.Doit написал 13 минут назад:
Drakonian написал 8 часов назад:

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

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

json и хмл

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

...

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

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

........

 

 

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

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

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

...........

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

DeadMage, madvlaydin и TRiPL3 понравилось это

Поделиться сообщением


Ссылка на сообщение
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 ендпоинт ходишь и выполняешь множество команд... ничего не смущает? )


 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение
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

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


 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение
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 задачу, пробрасывает текст команды на сервер и ответ тебе назад. Он не занимается исполнением команды.

DeadMage и Drakonian понравилось это

Торжество разума в том, чтобы уживаться с теми, у кого этого разума нет. Вольтер.
Чтобы хорошо высыпаться, нужно спать 8 часов в день. И еще столько же ночью.

Поделиться сообщением


Ссылка на сообщение
Drakonian написал Только что:
Just.Doit написал 3 минуты назад:
Drakonian написал 4 минуты назад:

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

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

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

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

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


 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение
Drakonian написал 1 минуту назад:

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

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


Торжество разума в том, чтобы уживаться с теми, у кого этого разума нет. Вольтер.
Чтобы хорошо высыпаться, нужно спать 8 часов в день. И еще столько же ночью.

Поделиться сообщением


Ссылка на сообщение
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 минут назад:

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

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

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

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

 


 

очень крутые котейки

RqvSzvr.png


Кому-то пизды дал - нужно сделать скрин обязательно. (с) Solo

Поделиться сообщением


Ссылка на сообщение
Гость
Эта тема закрыта для публикации сообщений.

×
×
  • Создать...