https://github.com/gohugoio/hugo/blob/master/main.go#L21

В общем так везде делают

А, тебе нужен относительный импорт в пределах твоего проекта?

нет, мне просто надо чтобы насчет src кстати помогло перенесение папки в src/morgoth и все взлетело... GOPATH указывает на корень в котором есть src/morgoth и src/vendor

Как можно архитектурно зарефакторить такой код? switch incomeEvent.Action { case models.CALL: switch incomeEvent.Method { case models.GET: getRequestHandler(incomeEvent) case models.POST: postRequestHandler(incomeEvent) } case models.SUBSCRIBE: switch incomeEvent.Method { case models.POST: postSubscribeHandler(incomeEvent) } } P.S. Внутри этих методов еще switch. Полиморфизм? Регистрация колбеков? Мб еще варианты есть? В golang новичок. Такая вложенность, еще и раскиданная по файлам мне не нравится

Было бы читабельно просто: switch "first_type": handler.first(incomeEvent) switch "second_type": handler.second(incomeEvent) switch "third_type": handler.third(incomeEvent) Или так: handler := getHandler(incomeEvent) handle.handle(incomeEvent)

А models.CALL и т.п. это константы?

Какого типа?

да, интовые

Пока мысли примерно такие: Events = map[string]string{ "request_messages": fmt.Sprintf("%s-%s", models.CALL, models.GET), "send_message": fmt.Sprintf("%s-%s", models.CALL, models.POST), }

Ну я регистрацией обычно такое делаю.

Мапа(лучше массив если константы позволяют), в которой соответствие константе функции.

Один из вариантов есть такой

И тестить потом проще будет

Вы по книгам го учите? Линкс?

Как можно архитектурно зарефакторить такой код? switch incomeEvent.Action { case models.CALL: switch incomeEvent.Method { case models.GET: getRequestHandler(incomeEvent) case models.POST: postRequestHandler(incomeEvent) } case models.SUBSCRIBE: switch incomeEvent.Method { case models.POST: postSubscribeHandler(incomeEvent) } } P.S. Внутри этих методов еще switch. Полиморфизм? Регистрация колбеков? Мб еще варианты есть? В golang новичок. Такая вложенность, еще и раскиданная по файлам мне не нравится

выглядит как шаблон observer https://gist.github.com/sayden/d3ab61726057b7a37963

Вы по книгам го учите? Линкс?

нет, я просмотрел на pluralsight курсы, параллельно с ноутбуком на коленках и с паузами: https://app.pluralsight.com/library/courses/go-fundamentals/table-of-contents https://app.pluralsight.com/library/courses/go-concurrent-programming/table-of-contents + я давно знаю другие языки, немного легче понять

выглядит как шаблон observer https://gist.github.com/sayden/d3ab61726057b7a37963

Реактивщина в golang?) Не приходило в голову)

Хотя чё, в java/node/js же есть

нет, я просмотрел на pluralsight курсы, параллельно с ноутбуком на коленках и с паузами: https://app.pluralsight.com/library/courses/go-fundamentals/table-of-contents https://app.pluralsight.com/library/courses/go-concurrent-programming/table-of-contents + я давно знаю другие языки, немного легче понять

Спасибо!

выглядит как шаблон observer https://gist.github.com/sayden/d3ab61726057b7a37963

Этот паттерн по сути реализуют каналы, только с разницей в синтаксисе и с буферизацией

Ну, если полный rx не рассматривать, а паттерн Observer

а я правильно понял текущую концепцию работы с database/sql ? повторно *Rows пройтись через .Next() нельзя??? т.е. надо обязательно после запроса профетчить и сложить куда нибудь себе в буфер? если хочешь повторно использовать?

Ребят, хотел бы узнать как правильно будет реализовать следующие. Есть СУБД, бэкенд на Го и фронт на Vue По ходу добавления новых записей в СУБД (Postgresql) на фронтенд должна передаваться эта запись. Как я вижу это: Триггер в СУБД срабатывает при добавление новой записи и отправляет запрос в бэкенд на го (с этой новой записью), на фронте раз в несколько секунд делается запрос к бэкенду на проверку новых записей и если есть, то получит его уже с бэкенда...

а я правильно понял текущую концепцию работы с database/sql ? повторно *Rows пройтись через .Next() нельзя??? т.е. надо обязательно после запроса профетчить и сложить куда нибудь себе в буфер? если хочешь повторно использовать?

эээ

а я правильно понял текущую концепцию работы с database/sql ? повторно *Rows пройтись через .Next() нельзя??? т.е. надо обязательно после запроса профетчить и сложить куда нибудь себе в буфер? если хочешь повторно использовать?

Ну сложи это себе в массив, а потом пройдись по нему и ищи что тебе нужно... или я вас не понял.

Ребят, хотел бы узнать как правильно будет реализовать следующие. Есть СУБД, бэкенд на Го и фронт на Vue По ходу добавления новых записей в СУБД (Postgresql) на фронтенд должна передаваться эта запись. Как я вижу это: Триггер в СУБД срабатывает при добавление новой записи и отправляет запрос в бэкенд на го (с этой новой записью), на фронте раз в несколько секунд делается запрос к бэкенду на проверку новых записей и если есть, то получит его уже с бэкенда...

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

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

Вроде того, что если кто добавил через этот бэкенд новую запись, то все его клиенты должны обновить свой items?

Ребят, хотел бы узнать как правильно будет реализовать следующие. Есть СУБД, бэкенд на Го и фронт на Vue По ходу добавления новых записей в СУБД (Postgresql) на фронтенд должна передаваться эта запись. Как я вижу это: Триггер в СУБД срабатывает при добавление новой записи и отправляет запрос в бэкенд на го (с этой новой записью), на фронте раз в несколько секунд делается запрос к бэкенду на проверку новых записей и если есть, то получит его уже с бэкенда...

Вместо запроса раз в несколько секунд может лучше рассмотреть ws?

Вроде того, что если кто добавил через этот бэкенд новую запись, то все его клиенты должны обновить свой items?

клиенты могут быть подключены к чему-то вроде publish-subscribe (например вебсокет или редис) и они автоматом смогут получать обновления

Вместо запроса раз в несколько секунд может лучше рассмотреть ws?

Можно поподробнее, не понимаю про что вы

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

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

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

Ну вот так я и предлагал изначально

Можно поподробнее, не понимаю про что вы

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

Ну вот так я и предлагал изначально

Зависит от конкретных целей задачи. Может слушать базу, может только по f5 обновлять данные, может с бэка отправлять после изменений в базе. Смотря что вы делаете)

Вообще лучше забудьте об опросе с клиента с интервалом навсегда)

Сами себя заддосите

Вообще лучше забудьте об опросе с клиента с интервалом навсегда)

я понимаю что это плохая мысль

Нужно по пабсаб почитать

Вообще лучше забудьте об опросе с клиента с интервалом навсегда)

до сокетов как делали?

А когда проблема появится (внезапно) - вы вообще ничего не сможете сделать, кроме как остановить сервер

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

посмотрел, на основе этого работает https://www.postgresql.org/docs/9.5/static/sql-notify.html никогда не сталкивался, интересно

до сокетов как делали?

так и делали, появилась проблема - пришло решение с вебсокетами

а если какой-нибудь firebase Cloud messaging юзать?

Можно пример реализации pub/sub на Go?

а если какой-нибудь firebase Cloud messaging юзать?

Он по сокетам проде работает?

Можно пример реализации pub/sub на Go?

я лично предлагал конкретно вот это. реализация на стороне редиса https://redis.io/topics/pubsub

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

Можно пример реализации pub/sub на Go?

Пакет http и gorilla/websocket, там в вашем случае скорее всего нечего делать, если нет всяких авторизаций и т.п.

Авторизация есть

я лично предлагал конкретно вот это. реализация на стороне редиса https://redis.io/topics/pubsub

В редисе сработал publish и исчез. Прослушал - досвидос, тут лучше кролика

В редисе сработал publish и исчез. Прослушал - досвидос, тут лучше кролика

не понял про исчез

В редисе сработал publish и исчез. Прослушал - досвидос, тут лучше кролика

Кролик?

Rabbitmq

кролик с персистент очередями - не для хайлоада решение

ну кто слушает события, тот услышит, если упал, то прослушал своё сообщение)

кролик с персистент очередями - не для хайлоада решение

Я не думаю, что у парня хайлоад. Скорее всего, для админа смотреть изменения в таблицах или для девелопера

ну кто слушает события, тот услышит, если упал, то прослушал своё сообщение)

зависит от требований - надо ли оффлайн события получать или нет

Извините не совсем понимаю как это будет выглядеть, как редис будет получать инфу о новых записях в БД Postgresql

Извините не совсем понимаю как это будет выглядеть, как редис будет получать инфу о новых записях в БД Postgresql

postgres будет слать в кролика/редис сообщения

Извините не совсем понимаю как это будет выглядеть, как редис будет получать инфу о новых записях в БД Postgresql

pg-notify

pg-notify

ааа

Извините не совсем понимаю как это будет выглядеть, как редис будет получать инфу о новых записях в БД Postgresql

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

Либо отлавливать на уровне бизнес-логики

Мне это даже более приемлемым кажется

зависит от требований - надо ли оффлайн события получать или нет

согласен. Если не нужен офлайн - проще с редисом

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

А на фронте напрямую ходят к редису за инфой, или через бэкенд?

ERROR: S client not available

на уровне бд шустрее же, не?

Либо отлавливать на уровне бизнес-логики

Мне это даже более приемлемым кажется

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

Блин, так ты хочешь не базу слушать, а отправлять при запросе в БД? тогда никакие pg_notify и redis не нужны, шли сразу в сокеты

А на фронте напрямую ходят к редису за инфой, или через бэкенд?

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

у меня было 2 хайлоад проекта на такой схеме на одной из старых работ.

на уровне бд шустрее же, не?

Заранее вряд ли об этом имеет смысл задумыаться

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

Смотрите что откопал https://github.com/go-redis/redis Правильно я понимаю, что для этого лучше сделать отдельный микросервис?

Смотрите что откопал https://github.com/go-redis/redis Правильно я понимаю, что для этого лучше сделать отдельный микросервис?

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

в 1 случае всё просто - без триггеров в базе/кролика и т.п.

есть даже сразу проекты вебсокет + пабсаб редиса https://github.com/cooperhewitt/go-pubsocketd

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

Думаю, что могут быть оба варианта

Тогда pg_notify -> redis -> go -> ws

Тогда pg_notify -> redis -> go -> ws

тогда можно так: pg_notify -> go -> ws

Вешается триггер на базу, который шлёт с помощью pg_notify publish в редис, go слушает редис, при сообщениях шлёт в ws клиенту

Вешается триггер на базу, который шлёт с помощью pg_notify publish в редис, go слушает редис, при сообщениях шлёт в ws клиенту

го может сразу pg_notify слушать ведь. там есть. listen

тогда можно так: pg_notify -> go -> ws

Можно и так

Вешается триггер на базу, который шлёт с помощью pg_notify publish в редис, go слушает редис, при сообщениях шлёт в ws клиенту

А клиент (ws) получается постоянно подключен через сокет к бэкенду и слушает обновления?

да

Спасибо

Теперь имею представление как это реализовать.

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

Не реклама

Видели?

Alexey Troyanov: http://xidea.online/

Лицензировать любой продукт jetbrains

Интересно с goland сработает?

Уже несколько лет назад появились такие сервера. Но лучше купить или получить бесплатно, если есть opensource-продукт

еще студ лицухи есть)

Ну так goland триал только? Я вот pycharm качаю CE

еще студ лицухи есть)

Эт у них?