микросервисы, горутины, gRPC, event driven development, etc etc

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

В горутине до таймера wg.Add после wg.Done в цикле wg.Wait

Понял, спасибо, пойду разбираться

ну тогда желаю вам удачи с tight-coupling'ом. Я им уже наелся, спасибо, мне хватит. я лучше 1 раз напишу качественный API, нежели на каждую версию приложения писать новые endpoint'ы.

у меня на фронте была такая ситуация с rest: на каждую страницу по эндпойнту. ужас дикий

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

Дык, это надо просто про "архитектуру приложений" читать, в отрыве от го. А на го - реализовывать. Начните с "написать свой фреймворк", все так делают.

Дык, это надо просто про "архитектуру приложений" читать, в отрыве от го. А на го - реализовывать. Начните с "написать свой фреймворк", все так делают.

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

Как правило, подсматривание архитектуру у соседа, юзаете. Постепенно приходит понимание, что в ней хорошо, ну а главное - что в ней плохо.

Вопрос больше про практику.

Как правило, подсматривание архитектуру у соседа, юзаете. Постепенно приходит понимание, что в ней хорошо, ну а главное - что в ней плохо.

Правильно советуете, но это пол-дела. Книжки-бестпректис это вторые полдела.

Ну, как бы, экосистема го, в основном, про "собери сам свою мечту". Бест практис приносят, как правило, извне.

Вот на примере вебни: в Гоше есть стандартная библиотека "сделай сам", есть echo, про роутинг и мидлварь искаропки + "остальное сам", есть beego - про "у нас есть все. Если чего-то нет, вам оно не нужно".

Вот последний в го смотрится чужеродно

Вопрос в том, что я пытаюсь понять как правильно сделать "сам"

я соберу мечту по наличию функционала, а не по качеству исполнения

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

отлично. Мой вопрос - где это узнать.

Если нужен "комплексный подход искаропки" - такого в экосистеме нет.

Нет, не нужен. Мне нужно узнать "как правильно сделать сам.

отлично. Мой вопрос - где это узнать.

В экосистемах более других языков

В экосистемах более других языков

Сомневаюсь, что "экосистема" - это корректнынй носитель информации для её изучения. Мне кажется "книга" или "видео" больше должно подойти как ответ.

по запросу не мало полезного https://duckduckgo.com/?q=best+practices+software+development&t=h_&ia=web

Книгу или видиву надо искать на тему что-то вроде "промышленное применение и архитектура фреймворка X на языке Y"

На место x и y подставляем, например java+spring

Я про то, что "правильная архитектура приложения на го" - плохая формулировка. Из нее слово "го" убрать, и будет норм запрос в Гугель.

хм.. вероятно, мне ваши ответы кажутся странными, т.к. все языки отличаются. Как я построю на другом языке приложение, если там нету (го)рутин?

Конкретно по Гоше само понятие правильной архитектуры сильно размывчато. На го переползают, в основном, те, кого не устраивают устоявшиеся архитектурные подходы и их ограничения

архитектура строится из особенностей языка имхо а не язык из особенностей архитектуры

Архитектура приложения и горутины - вещи ортогональные

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

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

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

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

Вовсе нет. Я сейчас не говорю о паттернах проектирования. Давайте это исключим из разговора. Архитектура приложений с пецифика реализации имхо связаны и я сказал почему. Я не прав?

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

Паттерны проектирования - это как раз набор рекомендаций по реализации этой самой архитектуре.

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

Возможно, так и есть. И я прошу отсыл к материалу про сие.

И один и тот же паттерн можно реализовать на миллионе языков.

Паттерны проектирования - это как раз набор рекомендаций по реализации этой самой архитектуре.

Это мне болеменее понятно.

И один и тот же паттерн можно реализовать на миллионе языков.

это тоже.

*умею синглтон на пыхе петоне и го ?

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

Го тут сильно сбоку, это детали реализации.

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

Как проектировать такую абстракцию, если системы нет? Я хочу "написать своё сам", но не вижу адекватных примеров или рекомендаций.

Давайте начнем с того, что конкретно вы хотите реализовать

Вам нужно копать в сторону паттернов и практики их применения

Паттерны я осмысливаю. Понимая паттерны, пока не понитмаю, где их нужно или не нужно применять, какой куда итд.

Дело в том, что, с точки зрения архитектуры приложения реализация паттерна на го, от реализации на пыхе

Ну вот го тут вообще не поможет

Нету готовых больших рецептов "конкретно для го"

Коллеги знает кто-нибудь утилиту для форматирования .gohtml? Вроде видел как-то экспериментальную тулзу но теперь что-то не могу найти ?

Говорю же, просто найдите рецепт архитектуры для java - их миллионы - и сделайте так же, но на го

Давайте начнем с того, что конкретно вы хотите реализовать

Хорошо. "хочу написать своё" - блохчейн с различными алгоритмами подтверждения - pos, pow, bft. Как мне понять, как правильно написать то, что я хочу написать? Сами алгоритмы известны(или станут таковыми). Но вопрос "архитектуры" всего этого. Я-то напишу сам не вопрос, функционал реализован будет. Боюсь, что его будет стыдно показать.

Говорю же, просто найдите рецепт архитектуры для java - их миллионы - и сделайте так же, но на го

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

Хорошо. "хочу написать своё" - блохчейн с различными алгоритмами подтверждения - pos, pow, bft. Как мне понять, как правильно написать то, что я хочу написать? Сами алгоритмы известны(или станут таковыми). Но вопрос "архитектуры" всего этого. Я-то напишу сам не вопрос, функционал реализован будет. Боюсь, что его будет стыдно показать.

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

Хорошо. "хочу написать своё" - блохчейн с различными алгоритмами подтверждения - pos, pow, bft. Как мне понять, как правильно написать то, что я хочу написать? Сами алгоритмы известны(или станут таковыми). Но вопрос "архитектуры" всего этого. Я-то напишу сам не вопрос, функционал реализован будет. Боюсь, что его будет стыдно показать.

Ну так возьмите пример реализации "блохчейна" на плюсах или джаве. В общем и целом архитектура будет та же. Задача сведётся к адаптации архитектуры

Ну так возьмите пример реализации "блохчейна" на плюсах или джаве. В общем и целом архитектура будет та же. Задача сведётся к адаптации архитектуры

ладно, ладно, этот ответ я понял, говорю же.

Собственно архитектура "блохчейна" - это последствия практического опыта, а не чтения книжек

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

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

Нету книжек "правильная архитектура xxx на го"

есть книжки "правильная архитектура xxx" ?

Го не навязывает архитектуру, он проектировался как раз как средство реализации любой архитектуры кусками

Есть

Паттерны проектирования

И все

И все

значит мир тлен а я идеалист?

Там вместо го, обычно, другой язык указан

А какая разница какой язык

Паттерны не меняются

ERROR: S client not available

Там вместо го, обычно, другой язык указан

Видел в книжном книжку про паттерны - там всё было на псевдокоде. Неужели архитектуры на псевдокоде нету

И классика банды четырех - как универсальный подход

на всякий случай кому вдруг

(увы пдф нет, купить хочу)

Видел в книжном книжку про паттерны - там всё было на псевдокоде. Неужели архитектуры на псевдокоде нету

Паттерны - это и есть "рекомендации по архитектуре"

потому и глаз положил на неё.

на сколько помню, там и алгоритмы и паттерны

хотя вот на соседнем канале там какой-то обсёр паттернов идёт

Если всё же про Go. Если погуглить что-то вроде Go design patterns Rob Pike, то ссылки будут про concurency patterns. И это неспроста. Фабрики, синглтоны, фасады и проч в Go тащат индусы, чтобы книжки продавать на Packt, и не слишком умные люди на собесах/в описаниях вакансий

на сколько помню, там и алгоритмы и паттерны

Алгоритмы и паттерны это разные вещи

Алгоритмы и паттерны это разные вещи

спасибо кеп

Если всё же про Go. Если погуглить что-то вроде Go design patterns Rob Pike, то ссылки будут про concurency patterns. И это неспроста. Фабрики, синглтоны, фасады и проч в Go тащат индусы, чтобы книжки продавать на Packt, и не слишком умные люди на собесах/в описаниях вакансий

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

про паттерны есть офигенский сайт https://refactoring.guru/ru/design-patterns

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

+

так.. я доехал до работы, отключаюсь )

а насколько уместно для DAO методы вида FindAll() []*Model или FindOne()*Model

Если всё же про Go. Если погуглить что-то вроде Go design patterns Rob Pike, то ссылки будут про concurency patterns. И это неспроста. Фабрики, синглтоны, фасады и проч в Go тащат индусы, чтобы книжки продавать на Packt, и не слишком умные люди на собесах/в описаниях вакансий

Вот на фасады и фабрики вы зря катите... Чем они вам в го помешали? Почитайте про паттерны, они, как бы, делятся на некоторые категории

а насколько уместно для DAO методы вида FindAll() []*Model или FindOne()*Model

А в чем проблема?

Вот на фасады и фабрики вы зря катите... Чем они вам в го помешали? Почитайте про паттерны, они, как бы, делятся на некоторые категории

Я, как видите, форварднул. Спросите автора.

А в чем проблема?

Там изначально вопрос что спрашивать/спрашивают на собесах по го

Какой стек технологии нужно знать Junior разработчику?

По какому направлению?

Пффф

Хз

Вебтехнологии

Пусть будут

Вебтехнологии

По какому направлению?

Бэкэнд

Какой стек технологии нужно знать Junior разработчику?

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

SQL, http, tcp/websocket