ну конечно, иного варианта нет, этим RPC собственно и не радует.

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

да, в ридми пример, если ты о моей либе говоришь

updates.getChannelDifference вот такой запрос сделать, а то сейчас не видно что появилось новое сообщение, в канале к примеру или нет

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

А я и не говорю что это решение на все случаи жизни. Мой пойнт в том, что не надо им пренебрегать

updates.getChannelDifference вот такой запрос сделать, а то сейчас не видно что появилось новое сообщение, в канале к примеру или нет

ты путаешь mtproto и tdlib. в tdlib нет такого метода. есть непрерывный стрим апдейтов, которые можешь фильтровать

ок, посмотрю что там есть

ок, посмотрю что там есть

в ридми пример

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

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

в ридми пример)

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

большой потенциал cross-request caching'а и batching'а на стороне сервера теряется. в GQL можно резолвить поля на loader'ы которые автоматом кэшируют и устраняют дубликаты и batch'ях запросы на бд насколько это производительнее сказать не могу, нет бенчмарков, но в теории это должно лучше распределять хаотичную нагрузку

А я и не говорю что это решение на все случаи жизни. Мой пойнт в том, что не надо им пренебрегать

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

большой потенциал cross-request caching'а и batching'а на стороне сервера теряется. в GQL можно резолвить поля на loader'ы которые автоматом кэшируют и устраняют дубликаты и batch'ях запросы на бд насколько это производительнее сказать не могу, нет бенчмарков, но в теории это должно лучше распределять хаотичную нагрузку

Вполне возможно, но тут много вопросов без ответа

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

однако по мере роста RPC интерфейса - растёт его семантическая сложность. s GQL она не растёт

У рест есть преимущество - проще в реализации, проще масштабировать

однако по мере роста RPC интерфейса - растёт его семантическая сложность. s GQL она не растёт

Не факт. Если база норм. организована и задачи не выходят за рамки применения РА, то может всё гладко меняться

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

Потом они начнут писать на PL/Ruby и все вернётся к рельсам

У рест есть преимущество - проще в реализации, проще масштабировать

с одним таким маааленьким подтекстом: проще до определённого момента 😄 а чем его проще масшбатировать я честно говоря не понимаю

с одним таким маааленьким подтекстом: проще до определённого момента 😄 а чем его проще масшбатировать я честно говоря не понимаю

Есть endpoint которые можно разносить сколь угодно по разным серверам, nginx все разрулит

Есть endpoint которые можно разносить сколь угодно по разным серверам, nginx все разрулит

это называется load balancing, и возможно это как с REST так и с GQL

Только с рест проще

или ты про шардинг?

Только с рест проще

чем проще то?

Тем что все сводится к прописыванию нужных апстримов

Тем что все сводится к прописыванию нужных апстримов

хочешь сказать традиционный load balancing на GQL не распространяется?)

хочешь сказать традиционный load balancing на GQL не распространяется?)

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

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

зачем?

нагрузка? ставишь несколько инстансов GQL сервера и перед ними round-robin load balancer в чём сложность то?

нагрузка? ставишь несколько инстансов GQL сервера и перед ними round-robin load balancer в чём сложность то?

Есть разница между две копии всего приложения

И две копии одного эндпоинт

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

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

аа, т.е. запустить несколько копий одной API это сложнее, чем реализовать несколько разных HTTP серверов с разной логикой.. I see, I see..

аа, т.е. запустить несколько копий одной API это сложнее, чем реализовать несколько разных HTTP серверов с разной логикой.. I see, I see..

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

В случае с рест это просто добавить пару строчек в нгинкс

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

в чём разница то?))))) вызыватьсё то будут только те самые 10% просто на больший ряд машин))

Смотри, нагрузка идёт на 10% всего апи, ты предлагаешь масштабировать путем поднятия инстансов всего апи, я предлагаю масштабировать только 10% апи

вообще то о чём ты говоришь называется microservices 🙂 когда ты шардишь своё приложение на независимые компоненты системы и добавляшь инстансов тому компоненту который больше всего нагружен. тут GQL и REST абсолютно не при чём..

в чём разница то?))))) вызыватьсё то будут только те самые 10% просто на больший ряд машин))

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

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

ещё раз, это называется микросервисы и никакого отношения к GQL/REST не имеет

вообще то о чём ты говоришь называется microservices 🙂 когда ты шардишь своё приложение на независимые компоненты системы и добавляшь инстансов тому компоненту который больше всего нагружен. тут GQL и REST абсолютно не при чём..

Ну вот да не причём, микросервисы апи не имеют конечно же)))

микросервисы можно пилить как на GQL так и на REST..

И снова к началу)))

микросервисы можно пилить как на GQL так и на REST..

Или даже на postgrest

Да, можно

Можно и на grpc

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

короче: подытоживаю: GQL устраняет underfetching, но сложнее в реализации REST проще, но решение underfetching'а со временем приводит к полнейшему аду спец-endpoint'ов который окажется сложнее реализации GQL если вы со мной не согласны то переубедит вас только описанная проблема, с которой вы возможно рано или поздно столкнётесь. в любом случае я желаю вам удачи и спокойной ночи! 😉

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

короче: подытоживаю: GQL устраняет underfetching, но сложнее в реализации REST проще, но решение underfetching'а со временем приводит к полнейшему аду спец-endpoint'ов который окажется сложнее реализации GQL если вы со мной не согласны то переубедит вас только описанная проблема, с которой вы возможно рано или поздно столкнётесь. в любом случае я желаю вам удачи и спокойной ночи! 😉

То самое необоснованное мнение?)))

а есть ли курсы на русском языке ?

на курсере

С Sublime разобрался, поставил новый gocode, новый GoSublime? Всё работает. Помогите в другом. Вот я хочу, чтобы при отсутствии адреса запроса на сервер был редирект на другую страницу

cannot assign очевидно

Как по-человечески делается?

Это не моя идея была, заменить метод

С Sublime разобрался, поставил новый gocode, новый GoSublime? Всё работает. Помогите в другом. Вот я хочу, чтобы при отсутствии адреса запроса на сервер был редирект на другую страницу

Default route что ли? Посмотрите go in practice книгу, там много примеров подобного рода

Всем привет! Хотел спросить про каналы, сейчас пытаюсь разобраться и не могу понять. У меня в main запускается канал: req = make(chan tgbotapi.Message, 5) go getPhoto() res = make(chan InstagramResponse, 5) Где req & res объявлены вот так: var ( req chan tgbotapi.Message res chan InstagramResponse ) В определённый момент запускаю канал: req <- *message и после необходимых действий делаю так: res <- InstagramResponse{"data", msg} Но канал не возвращается к make(chan InstagramResponse, 5). Или я что то не так понял, или я тупой) Буду благодарен за помощь

О, всё. Заработало как убрал у res пятёрку

С Sublime разобрался, поставил новый gocode, новый GoSublime? Всё работает. Помогите в другом. Вот я хочу, чтобы при отсутствии адреса запроса на сервер был редирект на другую страницу

Разобрался. Надо было всего лишь хандлить "/"

вот это очень круто: https://habr.com/post/423495

парни, какие минусы у embedded locks на структурах, типа такого var a struct {sync.mutex /* other fields */} => a.Lock(), a.field++, a.Unlock()

парни, какие минусы у embedded locks на структурах, типа такого var a struct {sync.mutex /* other fields */} => a.Lock(), a.field++, a.Unlock()

А почему должны быть минусы?

А почему должны быть минусы?

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

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

Кому то нравится более явное, кому то нет

вот это очень круто: https://habr.com/post/423495

А что именно круто? Это же вроде просто про либу умеющую использовать готовые модели

вот это очень круто: https://habr.com/post/423495

круто, апи хорош

Если написать на сайте что мол Machine Learining, AI, распознавание лиц, и вот это всё, будут легкие денюжки.

data mining, ICO, cloud, VR тоже вставляй

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

Деревья имеют и крупный недостаток — склонность к переобучению что-то мне не кажется, что результирующая модель может иметь или не иметь какую-то склонность к переобучению)

> результирующая? Почему результирующая? Исходная. Разные модели по-разному склонны к переобучению, чего тут размышлять

А что именно круто? Это же вроде просто про либу умеющую использовать готовые модели

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

> результирующая? Почему результирующая? Исходная. Разные модели по-разному склонны к переобучению, чего тут размышлять

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

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

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

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

+1

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

вот вот 👍

уже обученная модель может быть overfitted. но она не может "переобучиться" в процессе ее использования. если вы ее "дообучаете" - это не та же самая уже модель

какой-то фестиваль капитанства

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

Если заэмбеддить то Lock и Unlock будут частью публичного апи структуры - это в большинстве случаев нежелательно

вот вот 👍

Но в статье как раз про склонность алгоритма

Если заэмбеддить то Lock и Unlock будут частью публичного апи структуры - это в большинстве случаев нежелательно

👍

Всем привет, разбирался ли кто с godoc ? Какой bestway для документирования проекта? У golang в некоторых cmd/...... и readme.md есть и doc.go.. Не хочется вести документацию в двух разных файлах, или там иной смысл?