Понять, что такое микросервисы - не сложно. Понять как это должно выглядеть правильно и по каким принципам эта архитектура строится - задача посложней, особенно на старте. Вот перевод статьи Мартина Фаулера, которая освещает многие аспекты микросервисной архитектуры. Почитать для ознакомления стоит.

https://m.habr.com/en/post/249183/

В тему микросервисов, тут есть неплохая статья со сравнением протоколов gRPC(HTTP 2.0) и REST(HTTP 1.1).
Интересно, что gRPC - не текстовый, как его предшественник, а бинарный.

https://code.tutsplus.com/tutorials/rest-vs-grpc-battle-of-the-apis--cms-30711

Статья с отличными советами по структурированию приложений на Go.
Мне помогла во многом, особенно запомнился совет с использованием http.Handle, вместо http.HandleFunc.
Так правда намного удобней работать с разными сервисами, вроде базы данных.

https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091

Там FB свой мессенджер переписывает, и эт конечно интересно-полезно, хотя много чего не досказано. Понравились коменты с ХН:

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment:

- NumPy is 360K lines mostly C
- Postgres is around 2.1M of C
- Go 1.13 is around 1.5M of Go code
- Rust 1.37 is around 1.2M of Rust code iirc
- core llvm is around 3M of C++ iirc
...
A chat app is 1.7M. A chat app...

Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've worked together on something truly awesome, big and useful. But we all know that doesn't pay the bills and so here we are.

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat
To be fair, this is part of the problem ^

https://engineering.fb.com/data-infrastructure/messenger/
https://news.ycombinator.com/item?id=22466462

Да, конечно мерять все в SLOC это так себе метрика, но и пренебрегать ею неправильно.

Немного офтоп, но очень интересно.

📝 webpack двигается в сторону micro frontends.
Micro frontends - это идея микросервисов переложенная на фронтенд, то есть части страницы делятся на самостоятельные изолированные приложения. Эти части могут быть реализованы разными командами и на разном технологическом стеке.
https://micro-frontends.org

Представим себе крупный сервис с множеством функциональных частей: поиск, фильтры, каталог, реклама, навигация и т.д.
Очень часто эти части могут встречаться на одной странице, но при этом разрабатываться разными командами и с использованием разных подходов к разработке (ведь каждая команда лучше знает "как правильно" ;)). В этом случае встает некоторое количество вопросов, например:

Как разделить большую кодовую базу на микро-приложения?

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

Как части приложения могут "общаться" между собой?

Например, в условиях SPA (single page application) фильтры могут влиять на каталог.

Как обеспечить реиспользование зависимостей?

Например, на странице загружен блок, который использует react и redux. Чуть позже, на страницу, динамически, подъезжает второй блок, который тоже использует react. Проблема в том, что этот блок разрабатывается другой командой, собирается и релизится отдельно от первого. Здесь необходимо обеспечить совместимость двух блоков и реиспользование уже загруженных на страницу зависимостей - второй блок не должен заново загружать на страницу react, а должен реиспользовать уже загруженный.

Около месяца назад было предложено архитектурное решение для webpack https://github.com/webpack/webpack/issues/10352 и буквально несколько дней назад были сделаны первые демо.
Описание решения можно найти тут https://medium.com/@ScriptedAlchemy/bcdd30e02669, а потыкать можно вот эту демку https://github.com/mizx/mfe-webpack-demo

Если коротко, то идея заключается в том, что совершенно разные собранные бандлы могут реиспользовать различные части друг-друга - одни бандлы предоставляют (expose) свои части (например UI-компоненты или целое приложение), а другие бандлы эти части импортируют и используют.
Фича все еще в разработке

#webpack #webpack5 #microfrontends

Начал проходить новый курс. Хочу углубиться в Docker и k8s. Курс от одного из Docker Captain’ов, который в разработке больше 20 лет и программировал ещё в те времена, когда использовался Ms Dos, то есть я даже ещё тогда не родился.
Судя по тем нескольким эпизодам, которые я посмотрел - обещает быть интересным.
Поэтому, оставлю ссылку здесь: https://www.udemy.com/course/docker-mastery/

Кстати, оттуда же узнал, что маскот докера - это не кит, а вот эта потрясающая черепаха(вполне реальная). Периодически, она даже посещает офис компании.
Забавно, что пять лет назад, когда все только начиналось, черепаха была маленькой, как и сама компания, а теперь она огроменная и нужно двое людей, чтоб ее перенести.
https://twitter.com/gordonTheTurtle

Недавно было предложение о работе в cloudinary, которое всё еще в процессе обсуждения. Забавно, что за несколько дней до этого я начал писать обертку cloudinary для нужд @komfy. Так вот, сегодня я наконец закончил основную часть и могу ее показать. Конечно же критика принимается и очень желательна. Так что пишите мне своё мнение: @mlvni

Репо: github.com/komfy/cloudinary

До определённого момента вообще не понимал, как писать тесты. Особенно тесты для серверов, где нужно проверять как сервер отвечает на разные запросы. Буквально пару месяцев назад попалось под руку это видео. Просто, понятно и с примерами автор объясняет как правильно писать тесты на Go. Кроме этого, на канале у него уже более 40 видео о разных нюансах в Go.
https://youtu.be/hVFEV-ieeew

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

https://blog.golang.org/why-generics

Frontend фреймворк, написанный на go. Работает с помощью websocket.
Наверняка, это не станет новым реактом и не перевернет мир.
Но идея и реализация - интересные, стоит посмотреть.
К тому же, у проекта отличная документация с юзкейсами.
https://github.com/elliotchance/pepper

Обнаружил у Dave Cheney в блоге раздел “Practical Go”. Это подборка статей по написанию поддерживаемого го кода.
Круто, что все самое важное собрано в одном месте. Можно читать как продолжение к Effective Go.
https://dave.cheney.net/practical-go

С самого первого дня(то есть уже около года) веду конспект всего того, что учу, я уже рассказывал об этом раньше, здесь. Так вот, у меня накопилось около 30-и страниц на Google Docs и два полностью забитых бесплатных воркспейса в Notion.
Конечно, я его не редактировал, поэтому многое может быть описано не техническим языком.

Вот и сами конспекты.
Часть из них, например Docker, обновляется каждый день.
В будущем планирую немного их отредактировать.

Go - здесь Go и Docker
VanillaJS - здесь чистый js и jQuery
NodeJS - только Node и немного Mongo.

Интересная статья, о том как concurrency в go работает на нескольких потоках.
Спойлер : медленнее.

https://habr.com/ru/post/195574/

А ЧТО ЕСЛИ... дисковый набор никуда не исчез и используется до сих пор?

(3D-концепт от питерского дизайнера, страшный кошмар миллениала).

behance.net/gallery/89414463/Rotary-dial-in-todays-world

Интересный success case компании по уменьшению нагрузки на cpu с детально описанными методами профайлинга. Честно, до этого не знал про тул pprof, но теперь буду им пользоваться.
https://link.medium.com/xSKYJd8MJ4

Статья на medium. О микросервисах в medium. Кстати, они используют go на бэке.
https://link.medium.com/B7oFLWM5M4

Очень длинная и очень интересная статья о том, как работают os и что это вообще такое. Жаль, что на medium можно «похлопать» всего 50 раз.

https://link.medium.com/EUSGsLc6O4