ну раз красиво)

https://play.golang.org/p/FMRnLJDPEL https://play.golang.org/p/ERhRWL2KX5

это для тех, у кого скролл не работает?

Удобнее коды ответа логически правильные ловить

рест - маркетойдная выдумка) даже хуже, чем микросервисы) в целом, если апи поддерживает только get и post, и отдаёт при этом чё-нить типа 200\400 - уже ок. Завязываться на коды ответа - рак. а фронтам стоит открыть для себя события

рест - маркетойдная выдумка) даже хуже, чем микросервисы) в целом, если апи поддерживает только get и post, и отдаёт при этом чё-нить типа 200\400 - уже ок. Завязываться на коды ответа - рак. а фронтам стоит открыть для себя события

Всмысле, базовые 200\400\500 (ok, not found, need auth, error) все равно нужны же это же удобно или речь про более полную детализацию? что значит открыть события? сокеты? не холивара ради спрашиваю =)

Всмысле, базовые 200\400\500 (ok, not found, need auth, error) все равно нужны же это же удобно или речь про более полную детализацию? что значит открыть события? сокеты? не холивара ради спрашиваю =)

ну хочешь дрючь сервер "аяксом", хочешь возьми центрифугу

это уже ближе в сторону cqrs, когда у тебя 2 разных "интерфейса" для чтения и записи.

post запись, get - внезапно, чтение.

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

post запись, get - внезапно, чтение.

Мой любимый вопрос: что делать если в ответ на post пришло 302 Location? ;)

Мой любимый вопрос: что делать если в ответ на post пришло 302 Location? ;)

зависит от степени упоротости клиента. Но по факту это ошибка выполнения команды

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

зависит от степени упоротости клиента. Но по факту это ошибка выполнения команды

Это может прилететь из внешнего сервиса

Это может прилететь из внешнего сервиса

в смысле из внешнего? на твой эндпоинт?

в смысле из внешнего? на твой эндпоинт?

Не на мой. Вот ходим мы в процессе работы в условный я.маркет/гуглоапи. Постом. И прилетает нам редирект, что сервис переехал.

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

Микросервисы нужны далеко не каждому проекту. Микросервисы это когда у тебя огромный софт с огромной нагрузкой и огромной командой. В таком случае легче работать, потому-что каждый сервис... 1. отвечает за свою определённую задачу, и не более. 2. может содержать свои собственные базы данных и хранилища. 3. может быть написан на абсолютно любом языке с любым стэком технологий 4. может самостоятельно расти, независимо от экосистемы в которой он работает Я считаю, что начинать нужно с монолитной API, а потом делить её на микросервисы по мере роста проекта и команды, если это действительно потребуется, разумеется. В таком случае, изначальный монолит превратится в так называемый Gateway микросервисов.

Не на мой. Вот ходим мы в процессе работы в условный я.маркет/гуглоапи. Постом. И прилетает нам редирект, что сервис переехал.

в твоём случае ты проследуешь на новый локейшен.

У микросервисов есть и значительные недостатки, такие как больший overhead в коммуникации и повышенный latency, сложный deployment.. поэтому в самом начале проекта - руки проч от микросервисов)

Микросервисы нужны далеко не каждому проекту. Микросервисы это когда у тебя огромный софт с огромной нагрузкой и огромной командой. В таком случае легче работать, потому-что каждый сервис... 1. отвечает за свою определённую задачу, и не более. 2. может содержать свои собственные базы данных и хранилища. 3. может быть написан на абсолютно любом языке с любым стэком технологий 4. может самостоятельно расти, независимо от экосистемы в которой он работает Я считаю, что начинать нужно с монолитной API, а потом делить её на микросервисы по мере роста проекта и команды, если это действительно потребуется, разумеется. В таком случае, изначальный монолит превратится в так называемый Gateway микросервисов.

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

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

в твоём случае ты проследуешь на новый локейшен.

Со сменой метода или нет? :)

Со сменой метода или нет? :)

на гет

Монолиты довольно сложно мейнтейнить в большой команде, когда люди уходят и приходят и сам по себе проект огромный. Я сам знаю, какого это, поскольку работал в одной немецкой конторе где почти 80 человек трудились над 1 монолитным сервером раздачи Ad банеров.. весь этот проект в конце превратился в 5 независимых команд, каждая из которых ответвилась и начала пилить свой микросервис, когда с главного сервера сняли множество ответственностей.. правда на тот момент термин "микросервисы" ещё не был популярен походу

Монолиты довольно сложно мейнтейнить в большой команде, когда люди уходят и приходят и сам по себе проект огромный. Я сам знаю, какого это, поскольку работал в одной немецкой конторе где почти 80 человек трудились над 1 монолитным сервером раздачи Ad банеров.. весь этот проект в конце превратился в 5 независимых команд, каждая из которых ответвилась и начала пилить свой микросервис, когда с главного сервера сняли множество ответственностей.. правда на тот момент термин "микросервисы" ещё не был популярен походу

опять-таки, чем разделённые контексты монолита хуже, чем разделённые контексты микросервиса?)

опять-таки, чем разделённые контексты монолита хуже, чем разделённые контексты микросервиса?)

Монолит обычно написан на 1 стэке технологий, а это хреново, особенно с огромной командой. Один хочет на Node.js, другой на C++, третий на Go, четвёртый на Java'е, пятый на питоне...

Монолит обычно написан на 1 стэке технологий, а это хреново, особенно с огромной командой. Один хочет на Node.js, другой на C++, третий на Go, четвёртый на Java'е, пятый на питоне...

да хотеть человеки могут всё, что угодно) я вот хочу ничего не делать и бабло получать :)

опять-таки, чем разделённые контексты монолита хуже, чем разделённые контексты микросервиса?)

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

так а что мешает не нарушать api внутри монолита?

да хотеть человеки могут всё, что угодно) я вот хочу ничего не делать и бабло получать :)

ну хоти, однако представь себя на месте project manager'а, когда у тебя в дверь стучатся 3 отличных Go'фера, а твой монолит написан на C++

я почти месяц гошников собеседовал. То, что мне в двери сразу трое постучатся, хер поверю)

я почти месяц гошников собеседовал. То, что мне в двери сразу трое постучатся, хер поверю)

Ты не Microsoft, ты не Apple, ты даже не SAP ?

Ты не Microsoft, ты не Apple, ты даже не SAP ?

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

ещё раз повторюсь: большинству - микросервисы - не нужны. Они нужны реально большим конторам с реально большими командами

ну удобно побить микросервисы и каждому разработчику скормить по проекту ?

шо бы холи срачи не решать

ещё раз повторюсь: большинству - микросервисы - не нужны. Они нужны реально большим конторам с реально большими командами

с 1м соглашусь: пока на проекте полторы калеки, микросервисы лесом :)

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

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

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

ты упорно игнорируешь вопрос про контексты) ну да ладно :)

ты упорно игнорируешь вопрос про контексты) ну да ладно :)

какой?

опять-таки, чем разделённые контексты монолита хуже, чем разделённые контексты микросервиса?)

так а что мешает не нарушать api внутри монолита?

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

был уже ответ ^

и не один

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

так а что мешает не нарушать api внутри монолита?

что простите? не нарушать api внутри монолита?

что простите? не нарушать api внутри монолита?

именно. API - это не про микросервисы, не про http, ни про mq и т.д.

именно. API - это не про микросервисы, не про http, ни про mq и т.д.

суть вопроса не понятна

что такое Bounded context знаешь? просто не уверен, что мы с тобой говорим на одном языке.

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

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

всё сказал, да смысла мало)

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

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

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

что мне помешает в рамках монолита использовать надцать языков - только тебе известно :)

модуль != микросервис // true

ясна

можешь дальше не утруждаться :)

что мне помешает в рамках монолита использовать надцать языков - только тебе известно :)

забыл вас поздравить, вы изобрели микросервисную архитектуру, сэр! только почему-то назвали её монолитом, но это неважно

забыл вас поздравить, вы изобрели микросервисную архитектуру, сэр! только почему-то назвали её монолитом, но это неважно

думай так, как позволяет твоя квалификация.

троль детектэд))

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

Мне вообще слово «микросервисы» не нравится. По факту, все что про них пишут в интернете - это обычные сервисы из SOA. С чего они вдруг стали «микро», вообще не ясно. Микросервис - это когда ты уже дошел до запуска отдельных лямбд в выч. сети. А все остальное галимый маркетинг и подмена понятий

Мне вообще слово «микросервисы» не нравится. По факту, все что про них пишут в интернете - это обычные сервисы из SOA. С чего они вдруг стали «микро», вообще не ясно. Микросервис - это когда ты уже дошел до запуска отдельных лямбд в выч. сети. А все остальное галимый маркетинг и подмена понятий

микросервисы - просто ребрендинг соа. Просто соа слишком старый и уже плохо продаётся

Ну да, я про это же

к сожалению, в нашей профессии слишком много галимого маркетинга :)

и я не про микросервисы) а в целом

всякие ресты, солиды, аджайлы и т.д.)

hr-ы :D

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

Кроме проблем, от подхода есть профиты. Берите список профитов/непрофтов подходов, реальный проект, смотрите, какие бонусы роляют больше, выбираете

@onokonem

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

А при чем ошибки проектирования к микросервисам?

с 1м соглашусь: пока на проекте полторы калеки, микросервисы лесом :)

Вот это напоминает более ранние срачи на тему С/С++ и библиотек, надо ли на проекте выносить код в библиотеки или нафиг, если на проекте полтора землекопа

забыл вас поздравить, вы изобрели микросервисную архитектуру, сэр! только почему-то назвали её монолитом, но это неважно

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

Мне вообще слово «микросервисы» не нравится. По факту, все что про них пишут в интернете - это обычные сервисы из SOA. С чего они вдруг стали «микро», вообще не ясно. Микросервис - это когда ты уже дошел до запуска отдельных лямбд в выч. сети. А все остальное галимый маркетинг и подмена понятий

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

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

для того, что бы понимать чем микросервисы отличаются (споилер: ни чем) от соа, надо понимать что такое соа. Нет там никаких "микро". в целом странный наброс, к реальности отношения не имеющий

Поставьте @joinhider_bot

Поставьте @joinhider_bot

Ну поставь, чё. Создатель группы последний раз в мае заходил

Одмины, баньте этих китайцев. Заходите в Manage Group->Recent Actions и там в десктопе правой кнопой по мессаге джойна, а в мобилке - оттуда просто тыкать в польхователя, он будет опказывать профайл и внизу "ban from group"

А разве админы не могут добавлять бота?

Могут. Но не могут ему права дать админские

Точн

Одмины, баньте этих китайцев. Заходите в Manage Group->Recent Actions и там в десктопе правой кнопой по мессаге джойна, а в мобилке - оттуда просто тыкать в польхователя, он будет опказывать профайл и внизу "ban from group"

с айфона можно забанить прям через сообщение входа. вместе с репортом спама

1. Монолиты пишутся на одном языке, их можно расширять только вертикально. 2. Изначально лучше писать монолит, где каждый блок закрыт от другого и общение между блоками проходит через интерфейсы 3. Когда вертикального расширения не хватает/ хочется что-то написать на другом языке/ хочется использовать один сервис в разных проектах, рефакторим монолит до уровня микросервисов.

фанатики...)

1. Монолиты пишутся на одном языке, их можно расширять только вертикально. 2. Изначально лучше писать монолит, где каждый блок закрыт от другого и общение между блоками проходит через интерфейсы 3. Когда вертикального расширения не хватает/ хочется что-то написать на другом языке/ хочется использовать один сервис в разных проектах, рефакторим монолит до уровня микросервисов.

монолит не означает, что у тебя только один deployment unit

микросервисы - это не синоним кучи говнокода на разных языках

микросервисы - не синоним заоопарка языков. Монолит не ограничен одним.

монолит не означает, что у тебя только один deployment unit

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

и что мне должно в этом помешать?)

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