Телеграмм чат группы golang_ru страница 762

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Golang Developers — русскоговорящее сообщество

360 membersпожаловаться на группу

2020 October 29

D

Dmitry in Golang Developers — русскоговорящее сообщество

можно и без интерфейсов ))
только "можно" не значит "удобно" ))

тестировать неудобно бывает и сопровождать )
а так - да ))

главное не переборщить, а то выйдет
ControllerInterface -> ControllerBase -> ControllerFabric -> SomethingController когда этот контроллер один все, всегда, на весь проект :)

источник

12:07пожаловаться #1

А

Андрей in Golang Developers — русскоговорящее сообщество

Анатолий

ну я в жс писал интрефейсы и использовал фабрики, в пхп тоже работает и без этого ;)

Я к тому, что как-минимум половина современного кода на js/ts все еще не использует ооп. Раньше тем более. А в php любой фреймворк 5-летней давности уже обязывает писать ооп. Но да, можно даже в функциональном стиле писать)

источник

12:07пожаловаться #2

D

Dmitry in Golang Developers — русскоговорящее сообщество

Я к тому, что как-минимум половина современного кода на js/ts все еще не использует ооп. Раньше тем более. А в php любой фреймворк 5-летней давности уже обязывает писать ооп. Но да, можно даже в функциональном стиле писать)

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

источник

12:08пожаловаться #3

А

Андрей in Golang Developers — русскоговорящее сообщество

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

Ответ выше и к вашему сообщению подходит)

источник

12:08пожаловаться #4

D

Dmitry in Golang Developers — русскоговорящее сообщество

yii вообще там мрак и ужас

"стандарт" js express это же ад с точки зрения архитектуры :(

источник

12:09пожаловаться #5

А

Андрей in Golang Developers — русскоговорящее сообщество

ТС без интерфейсов, абстрактных классов и декораторов 🤨

На гитхабе много кода просто с типизацией. Да и мало еще ts)

источник

12:10пожаловаться #6

т

тим in Golang Developers — русскоговорящее сообщество

На гитхабе много кода просто с типизацией. Да и мало еще ts)

На гитхабе ещё много плохого кода)

источник

12:11пожаловаться #7

D

Dmitry in Golang Developers — русскоговорящее сообщество

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

источник

12:11пожаловаться #8

А

Андрей in Golang Developers — русскоговорящее сообщество

Сейчас часто поднимаются вопросы «нужен ли ооп, когда в моде микросервисная или сервис-ориентированная архитектура»

источник

12:15пожаловаться #9

А

Андрей in Golang Developers — русскоговорящее сообщество

Конечно ооп - это не обязательно наследование)

источник

12:16пожаловаться #10

D

Dmitry in Golang Developers — русскоговорящее сообщество

вот именно что "в моде", люди просто слабо понимают зачем микросервисная архитектура

источник

12:16пожаловаться #11

D

Dmitry in Golang Developers — русскоговорящее сообщество

такая архитектура в 99% случаев оверхед и не нужна вообще

источник

12:16пожаловаться #12

D

Dmitry in Golang Developers — русскоговорящее сообщество

да и как отсутствие или наличие ооп связано с микросервисами я не понимаю

источник

12:17пожаловаться #13

А

Андрей in Golang Developers — русскоговорящее сообщество

такая архитектура в 99% случаев оверхед и не нужна вообще

Да, я пробовал поднимать микросервисы в рабочем проекте. Пока отложил эту идею

источник

12:18пожаловаться #14

D

Dmitry in Golang Developers — русскоговорящее сообщество

Да, я пробовал поднимать микросервисы в рабочем проекте. Пока отложил эту идею

ради фана или была необходимость ?

источник

12:19пожаловаться #15

А

Андрей in Golang Developers — русскоговорящее сообщество

да и как отсутствие или наличие ооп связано с микросервисами я не понимаю

Меньше сервис, меньше кода

источник

12:19пожаловаться #16

D

Dmitry in Golang Developers — русскоговорящее сообщество

Меньше сервис, меньше кода

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

прям куча преимуществ сразу :)

источник

12:21пожаловаться #17

А

Андрей in Golang Developers — русскоговорящее сообщество

ради фана или была необходимость ?

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

источник

12:22пожаловаться #18

D

Dmitry in Golang Developers — русскоговорящее сообщество

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

т.е писать в удаленный сервис быстрее чем писать в то же хранилище но в монолите ?

источник

12:22пожаловаться #19

т

тим in Golang Developers — русскоговорящее сообщество

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

Ну насчёт скорости монгодб возникают вопросы

источник

12:23пожаловаться #20