скажите прямо - просто привычнее )

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

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

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

у вас в смысле бэка контейнер падал?

На чем бек был?

Граф просто стандарт реста, не пойму о чем вы

@artalar не подскажешь какой нибудь мега доклад или статью, где сжато и по существу обьяснется чем графкуель лучше реста

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

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

Это просто дело в том что девы работали с рестом и не знали как работать с графом

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

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

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

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

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

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

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

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

Все верно проблему выборки переносим с разрабов клиента на бек

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

Ага. Так фишка графкуэль в удобстве для фронта. Если за это приходится платить глючным тормознутым Беком оно того не стоит. Бек держит - графкуэль хорошо

Оптимизировать / грамотно составить запросы - вообще не кейс Реста/графа - это отдельная сущность

Ага. Так фишка графкуэль в удобстве для фронта. Если за это приходится платить глючным тормознутым Беком оно того не стоит. Бек держит - графкуэль хорошо

ну тобишь как под ковёр грязь замести

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

Составил модельку и простым языком запросов получил ее и то что тебе нужно - очень удобная штука

Но на практике когда заикаешься Беку про графкуэль у них волосы начинают шевелиться

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

но под нагрузкой и для прода он не годится

как вы решаете проблемы когда вам надо blob передавать?

Зависит от того где он лежит. Если на серваке, то просто создаю папочку, шарю её и шлю адрес файла

Все верно проблему выборки переносим с разрабов клиента на бек

не, когда с клиента надо передать

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

я правильно понимаю что речь про websocket?

соап не застал. обмен xml'ами видел только в легаси банковского по (проблевался)

Нужно больше фото этого слайда!

соап не застал. обмен xml'ами видел только в легаси банковского по (проблевался)

Фух благо я не работал с ним, я работал только на c# wpf с его xaml боже такое говно это ппц

@artalar не подскажешь какой нибудь мега доклад или статью, где сжато и по существу обьяснется чем графкуель лучше реста

Сейчас же шарп нормас. (Ну я только на дотнете писал, про виндовс формы не могу сказать)

Виндовс формы это другое чем wpf) wpf весь дизайн через ублюдский xaml

Фух благо я не работал с ним, я работал только на c# wpf с его xaml боже такое говно это ппц

но под нагрузкой и для прода он не годится

Этот же wpf устарел или я чёт путаю?

Дйствтлн у Фейсбука же нет нагрузки.... Все от задач зависит, конечно это не серебряная пуля

у тебя фраза - паразит

у тебя фраза - паразит

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

Дйствтлн у Фейсбука же нет нагрузки.... Все от задач зависит, конечно это не серебряная пуля

это не моё мнение. повторяю, что слышал такое мнение

Нет, не устаревал.

Я чёт помню хотел на шарпе написать десктопное приложение и в VS Studio в шаблонах WPF шла с .Net 4.5, а вот эти UPF (или как-то так) с .net core

Сейчас WPF и WinForms под кором спокойно идут.

А WPF на лине естественно не запустить? Там можно под GTK сейчас писать или mono уже все пускает в линуксе?

Не запустить. WPF намертво привязана к винде.

Если ты не освоил, то не значит что это говно)

Html and css на несколько голов выше xaml по моему скромно у мнению конечно, я понимаю что это разное, но я сужу лично по потраченным усилиям и удобством разработки

Html and css на несколько голов выше xaml по моему скромно у мнению конечно, я понимаю что это разное, но я сужу лично по потраченным усилиям и удобством разработки

Ещё раз: не сумел освоить != говно. Такое бывает, что не сумел познать.