Чтобы html рендерил?

а зачем в go-starter-kit node.js?

Собрать bundle.js

Чтобы html рендерил?

Нет, рендер делает duktape

а всё вижу, не прочитал в проекте

Добро пожаловать в чат "Golang RU", @m0sth8! Добро пожаловать в чат русскоязычного комьюнити языка программирования Go! Здесь не любят и активно карают за: — оскорбления; — nsfw контент; — флуд, флейм и спам; — избыток оффтоп тем; Список всякой всячины: https://github.com/avelino/awesome-go Ништяки: https://github.com/golang/go/wiki/Projects Сайт комьюнити: http://4gophers.ru/ Список проектов, которым нужны контрибьютеры: https://github.com/ninedraft/gocryforhelp Приятно провести время! :3

Ура, Слава пришел

всем привет

Ура, Слава пришел

Ведет golangshow, если вдруг кто то не знал

всем привет

Однако здравствуйте :3

Привет)

Ведет golangshow, если вдруг кто то не знал

Предупредлать надо, мыб чатик лепестками посыпали

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

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

Мне саблайм вообще всё заменяет

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

А что за контекст? Другой чат?

Здесь вроде было

А что за контекст? Другой чат?

Да нет, в комментариях к подкасту (

Здесь вроде было

Да я уже его везде "пропиарил"

Слепить надо через @vote опрос

Похоже у меня одного такие специфичные вкусы

[Из песочницы] Пишем backend на go с минимальными усилиями при помощи GoJs https://habrahabr.ru/post/301762/

мне нужны контрибьютеры

[Из песочницы] Пишем backend на go с минимальными усилиями при помощи GoJs https://habrahabr.ru/post/301762/

Мне одному кажется, что по Го очень много статей в стиле "Пишем веб-сервис/криптовалюту/скайнет за пять минут в триста строк" ?

дыа

мне нужны контрибьютеры

Куда?

сюда, например https://github.com/bot-api/telegram

Мне одному кажется, что по Го очень много статей в стиле "Пишем веб-сервис/криптовалюту/скайнет за пять минут в триста строк" ?

"Я слепил его из Go и микросервисов"

сюда, например https://github.com/bot-api/telegram

Сделано

Мне одному кажется, что по Го очень много статей в стиле "Пишем веб-сервис/криптовалюту/скайнет за пять минут в триста строк" ?

Нет, но горшочек продолжит варить и дальше

Ребята, кто что думает про микросервисы?

Именн атомизация на функции, а не SOA, как всегда было раньше

Уже второй проект встречаю где микросервисов под 30 штук, мне кажется это overkill

Уже второй проект встречаю где микросервисов под 30 штук, мне кажется это overkill

Поддержка развертывания и инфраструктуры займет все время, вероятно

Ребята, кто что думает про микросервисы?

ИМХО идея здравая (в смысле, тупенькие простенькие кирпичики всегда приятнее, чем здоровенная бандура ф-ля-давайте-напишем-что-то-вроде-ядра) С другой стороны хорошо-бы без фанатизма, типа когда у нас есть микросервис, который правильно расставляет отступы в документе

ИМХО идея здравая (в смысле, тупенькие простенькие кирпичики всегда приятнее, чем здоровенная бандура ф-ля-давайте-напишем-что-то-вроде-ядра) С другой стороны хорошо-бы без фанатизма, типа когда у нас есть микросервис, который правильно расставляет отступы в документе

Где граница?

Поддержка развертывания и инфраструктуры займет все время, вероятно

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

Где граница?

Когда микросервисов в проекте больше, чем разработчиков :3

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

Когда микросервисов в проекте больше, чем разработчиков :3

Кстати, годная метрика

Когда микросервисов в проекте больше, чем разработчиков :3

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

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

Ну в теории же всегда все хорошо :)

ну да )

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

Причем, сервис можно будет просто выкинуть и переписать. Как Uber недавно, например, переходил с Ноды.

Пр таком подходе есть проблема с отладкой и согласованностью версий апи(библию микросервисов не читал пока)

В этом то вся пока и проблема для меня. Слишком много вариантов.

Причем, сервис можно будет просто выкинуть и переписать. Как Uber недавно, например, переходил с Ноды.

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

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

монолит наше всё

ну т.е. вероятно оценка необходимости по О большой может помочь, в теории )

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

Принцип разделения отлично работает на алгоритмах, но тут не меряется сложность алгоритма.

монолит наше всё

Фленеган тоже так считает

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

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

Все-таки основной критерий — здравый смысл и техническая необходимость. Для меня микросервис это пакет. При необходимости пишем `cmd/$SERVICENAME/main.go`-обертку и получаем микросервис. Но нужна инфраструктура, а это нужно подсесть на что-то одно. Kubernetes тот же.

Как быть с реестром этих сервисов, логг рованием, health check?

Все-таки основной критерий — здравый смысл и техническая необходимость. Для меня микросервис это пакет. При необходимости пишем `cmd/$SERVICENAME/main.go`-обертку и получаем микросервис. Но нужна инфраструктура, а это нужно подсесть на что-то одно. Kubernetes тот же.

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

Как быть с реестром этих сервисов, логг рованием, health check?

Как деплоить, версионировать. Я правда сомневаюсь что небольшая команда способна потянуть поддержку всего этого, если будет сама велосипедить.

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

Если дать каждому по одному микросервису, все встает на свои места :)

Пишешь на чем хочешь, поддерживаешь свой код как нужно и тд и тп

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

Да, именно поэтому для меня микросервис — это пакет. Если у вас это уже сейчас не отдельный кусок кода, то сервисы вам не нужны. А если есть инфраструктура и готовый пакет, то при необходимости сервис сделать не проблема.

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

Пишешь на чем хочешь, поддерживаешь свой код как нужно и тд и тп

Это вин, конечно.

Что проще поддерживать? Ведь это самый важный показатель качества по

https://www.manning.com/books/the-tao-of-microservices вроде хвалят уже после вступления. сам еще не добрался.

Пишешь на чем хочешь, поддерживаешь свой код как нужно и тд и тп

>Пишешь на чем хочешь не сказать, чтобы прям преймущество

>Пишешь на чем хочешь не сказать, чтобы прям преймущество

Свобода от легаси

Вообще, я уже с год вынашиваю микросервисную архитектуру на NATS, но пока не было необходимости. Есть и обертки-генераторы с Thrift, и балансировка, дискавери. Версионировать можно по топикам.

Свобода от легаси

Предполагается что один человек никогда себе же не оставляет легаси, так а делает все правильно с первого раза :D

Вообще, я уже с год вынашиваю микросервисную архитектуру на NATS, но пока не было необходимости. Есть и обертки-генераторы с Thrift, и балансировка, дискавери. Версионировать можно по топикам.

Это все привнесенная сложность, дает ли она преимущество, вот вопрос

Свобода от легаси

Ну на практике это работает, раз Uber переписал разом сервис с Node на Go и счастливы.

Именно! Ключевое слово сервис

А не микросервис

Обертки — да, лишнее. А сервис-дискавери вещь нужная. NATS в этом плане дает примерно то же что Kubernetes, причём одним бинарником на Go.

Обертки — да, лишнее. А сервис-дискавери вещь нужная. NATS в этом плане дает примерно то же что Kubernetes, причём одним бинарником на Go.

Про очередь речь, да?

NATS? Не, это кластерная мессаджинг-система. Там есть очереди, но они скорее с клиентской стороны.

Ими как раз балансировать можно.

Грубо — просто транспорт. Шлешь нагрузку в топик, а дальше кому придет уже не твоя проблема.

Ну это и есть основной юзкейс очереди же

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

А какой именно инструмент, наверное не очень сильно важно

Ну это тонкая грань. Если использовать очередь для роутинга, то это все же оверкил. Messaging system (message bus) объединяет сервисы, работает транспортом. Там нет персистентности, at least once delivery и т.д.

у нас тупой http

между сервисами

без всяких очередей

у нас тупой http

Даже не rpc и stdlib?

Все как у людей. :) А service-discovery, версионирование?

rpc поверх http

без всяких очередей

Как авторизация сервисов происходит? Просто в подсети без авторизации или есть слой на уровне приложения?

авторизация?

зачем?

это же внутренние сервисы

Это ответ на мой вопрос

Вот удивительная вещь. Все знают, любят, всем нравится, но никто толком не знает как их готовить. :)

в спотифае знают

Да все серьезные знают. У Гугла того же изначально сервисная архитектура. Контейнерами деплоили еще когда никто не знал про cgroups.

сервисы != микросервисы же

Ну это холиварная тема. В их условиях любой микросервис в итоге в GAE вырастает :)

Т.е. с точки зрения терминологии и юзкейса, URL Fetch API, Mail API в App Engine — это микросервисы или нет?