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

Привет! Скажите, пожалуйста, разумно/правильно ли использовать кодогенерацию для формирования getters/setters к неэкпортируемым полям структуры?

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

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

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

А разве на уровне graphql его не нужно учить откуда данные брать?

Не очень понимаю как там получается меньше кода

Мне кажется удобство только со стороны фронта

Мне кажется удобство только со стороны фронта

?. но так как фронт тоже я ...)) аргумент принимается

@madgopher

a

что такое

ситуация сложнее. fasthttp слегка убогий

спорно

то же самое могу сказать о net/http

я могу сказать такое о го вообще

с одной стороны заебись, с другой заебешься

но это жи срач будет

я могу сказать такое о го вообще

а чё срач? и так всем известно.

Не очень понимаю как там получается меньше кода

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

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

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

хорошо

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

такое себе

такое себе

и правда, SQL тоже мусор

и правда, SQL тоже мусор

с фронта любое дербмо может прийти

а sql в твоем коде

с фронта любое дербмо может прийти

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

с фронта любое дербмо может прийти

то же дерьмо, что в не-graphql. Это называется http-запрос

которых нет, кстати в rest

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

так я могу не через спеку слать любой http

как по мне, так для rest можно gateway сделать на nginx впереди... а для графкуэль... нужно будет что-то другое городить, короче сложнее.

как по мне, так для rest можно gateway сделать на nginx впереди... а для графкуэль... нужно будет что-то другое городить, короче сложнее.

это же тот же самый http

так я могу не через спеку слать любой http

лол, graphql это не сетевой протокол

ничего не надо городить

так я могу не через спеку слать любой http

ну шли. получишь 400. в rest тоже можешь слать. Тоже получишь 400.

ничего не надо городить

А как делается балансинг на графкуэль? Чем?

это SQL натянули на реалии современной разработки

А как делается балансинг на графкуэль? Чем?

аа ты про это. это я хз

А как делается балансинг на графкуэль? Чем?

что ты имеешь ввиду? чем тебе не нравятся любые тулзы, которые ты юзаешь для рест?

что ты имеешь ввиду? чем тебе не нравятся любые тулзы, которые ты юзаешь для рест?

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

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

а как ты сейчас балансиурешь?

а как ты сейчас балансиурешь?

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

то есть они на разных серверах?

почему нет

я спрашиваю

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

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

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

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

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

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

а?!

а?!

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

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

а там внутри еще 20 запросов для полей, которые потом будут выкинуты

Ну скорее всего у тебя graphql будет работать поверх уже готового db слоя, который будет делать одинаковые запросы в контексте сущности. Опускаться до уровня выбора нужных колонок никто не будет. Поэтому из базы вытащишь n колонок, на фронт вернёшь одну.

колонки можно фильтровать и на rest c таким же успехом...

колонки можно фильтровать и на rest c таким же успехом...

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

у меня вопрос по организации проекта. сейчас мой исходник лежит по такому вот пути ~/go/src/rt - в домашней директории. репозиторий .git у меня сейчас находится в ~/go/.git это видимо неправильно... да?!?

да, это неправильно

зачем вы целиком весь гошный src под гит запихали? Вам в гит конкретно ваш проект пихать надо.

тем более, что даже не src, а целиком gopath

зачем вы целиком весь гошный src под гит запихали? Вам в гит конкретно ваш проект пихать надо.

спасибо, ща поправим. Поначалу не очевидно было.

собственно, .git должно быть ВНУТРИ проекта, а не снаружи

т.е. оно отслеживает файлы от текущей папки и глубже

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

не-не-не

монорепозиторий - это к вопросу о том, что считать проектом

1 проект = 1 репа

ERROR: S client not available

а монорепозиторий - это про "носите все в одном проекте"

Народ, В логрусе можно добавлять в вывод свои поля с помощью WithFields. А есть возможность, наоборот, убрать поля, к примеру level?

Есть редис, например я упрусь в то что редис перестанет в определенный момент справлятся, зделаю кластер

поможет ли это для команд увеличение перфоманса INCR/GET ?

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

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

если ключи разные

=(

Народ, В логрусе можно добавлять в вывод свои поля с помощью WithFields. А есть возможность, наоборот, убрать поля, к примеру level?

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

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

А чем пользуетесь?

А чем пользуетесь?

есть максимально абстрактный логгер у go-kit, но он не самый быстрый

долго подбирает слова

может нажал карманом

Это ж просто бот какой-то скорее всего

Разве что бот, работающий через юзерский API

А чем пользуетесь?

structlog и zap. structlog - минималистичный. для всех выглядит как наколенная поделка :) но мы его написали в 2015 как раз чтобы выпилить логрус. дополнительное достоинство - генерирует читабельный глазами лог. zap - без рефлексии. в результате вызов довольно громоздкий, но zap из всех самый быстрый.

ну кстати под go-kit логгер можно любой другой подсунуть, тот же zap

structlog и zap. structlog - минималистичный. для всех выглядит как наколенная поделка :) но мы его написали в 2015 как раз чтобы выпилить логрус. дополнительное достоинство - генерирует читабельный глазами лог. zap - без рефлексии. в результате вызов довольно громоздкий, но zap из всех самый быстрый.

Спасибо, обязательно погляжу. )

Есть еще zerolog, который постоянно соревнуется по скорости с zap'ом

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

нас тут хотят пригласить на митап - я, если что, согласовал

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

да

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

есть несколько адептов, которые его продвинают, и используют. в принципе - он иделогически лучше реста

Всем привет! Мы запускаем серию митапов «Be Mobile» ??? Приходите 26 сентября на первый митап по мобильной разработке от Билайн. Программа митапа: 18:30—19:00 Регистрация; 19:00—19:45 Григорий Серебряный (Билайн) — RIB архитектура и ее применение за пределами UBER; 19:45—20:30 Вячеслав Черников (Binwell) — Rapid Software Design; 20:30—21:00 Нетворкинг и пицца. Участие бесплатное, требуется предварительная регистрация по ссылке: http://beeline.apptractor.ru/#rec65777433 Переходи скорее, количество мест ограничено! ?Москва, Краснопролетарская улица, дом 4, 3 подъезд, штаб-квартира Билайн

йн

дописал)

не - так интереснее. на встречу надо взять с собой катану...

Всем привет! Мы запускаем серию митапов «Be Mobile» ??? Приходите 26 сентября на первый митап по мобильной разработке от Билайн. Программа митапа: 18:30—19:00 Регистрация; 19:00—19:45 Григорий Серебряный (Билайн) — RIB архитектура и ее применение за пределами UBER; 19:45—20:30 Вячеслав Черников (Binwell) — Rapid Software Design; 20:30—21:00 Нетворкинг и пицца. Участие бесплатное, требуется предварительная регистрация по ссылке: http://beeline.apptractor.ru/#rec65777433 Переходи скорее, количество мест ограничено! ?Москва, Краснопролетарская улица, дом 4, 3 подъезд, штаб-квартира Билайн

город добавьте

default же

ну вот, теперь читать всё объявление, что б понять что зря читал

а где progo? что с ним?