Не сочтите за негатив, но в меня зацепила фраза про переход от swift к object-c, как только вы стали себя чувствовать более менее комфортно. Если честно, то постоянно увеличивающийся разный объем данных которые нужно усвоить это абсолютно нормально для профессии (если не стагнировать). Мне кажется, вам очень повезло и вы по сути получили предварительный опыт работы в ИТ. Если это вводит вас в состояние неконтролируемого стресса, то я бы рекомендовал повторно поставить себя вопрос о необходимости входа в ИТ.
OIDC прексрасная вещь, но все же не тривиальная. Недавно делал библиотеку и вместо проекта на один вечер, это вылилось в две недели каждый день по 4-5 часа после работы.
Клиентов много, каждый клиент представляет собой независимое вычислительное устройство. Гораздо дешевле поставить дешёвый сервер и переложить весь рендер на клиента тем самым массово и бесплатно распараллеливая обработку.
Во-вторых, при использовании SPA вы практически автоматом получаете и UI и API. Если точное - UI становится просто обёрткой над стандартным API. Не нужно дублировать работу и клиентам максимально удобно интегрироваться.
Последнее - backend становится полностью независимым от UI, может разрабатываться разными командами и на разных языках (в отличие от SSR с гидрацией, который обычно требует одной платформы - node, позволяя делать универсальный код и для сервера и для клиента).
Более того, хорошо написанный фронт будет работать быстро и потреблять мало место (chunk, lazy load, etc...). И полировать и релизить его можно не меняя сервер
At least once - точно доставит, но возможно больше одного раза At most once - может доставит, может нет, но точно не более одного раза Exactly once - точно доставит, и точно не более одного раза.
Для exactly once требуется хранить в том или ином виде состояние на клиенте: offset/ключи корреляци и тп. Самый дорогой вариант. Более того, для поддержки exactly once, требуется поддержка и отправителя и получателя
Fyne очень тяжелый. Я на него возлагал большие надежды, но на Линуксе и Маке более-менее реалистичное приложение (много экранов, уведомления, таблицы...) ест батарейку и память больше чем хорошо написанное приложение на электроне.
Спустя полгода мучений управления k3s я понял, что на небольших сетапах кубер просто не нужен и мешает (можно обойтись ансиблом или номадом), а на больших лучше сразу полноценный дистрибутив использовать.
Небольшой отчет кому это может быть интересно. После этой наводки я поставил себе ZeroTier controller + zero-ui. Сначала нативно, потом без проблем перенёс в личный кубернетес.
Надо сказать товарищи из ZT сделали гигантскую работу по упрощению запуска контроллера. Все мои потребности закрывает на 100%.
Из положительных моментов, контроллер по умолчанию становится релеем (хотя в доке указано обратное). В локальной сети ZT автоматически устанавливает локальный маршрут.
Собственный контроллер кроме ощущение контроля даёт ещё и безлимитный объем сетей и подключенных узлов (да, у меня сетевых устройств больше чем бесплатный лимит).
Я склонен с вами согласиться, хотя и долгое время был поклонником tinc (даже статьи писал). Однако, я так и не нашёл аналогичную систему, которая умела бы автоматически пересылать трафик между узлами через посредников. Nebula , Tailscasle, ZeroTier полагаются во многом на пробив NATa, что не всегда возможно. TS, ZT хотя бы умеют использовать свои сервера при недоступности оконечных узлов, однако идея пускать траффик через сервера третьих лиц меня пугает.
Ещё бывают ситуации, что архитектуру детально прописываешь, согласовываешь, создаёшь RFC, рисуешь диаграммы разного уровня детализации, составляешь секцию FAQ, а потом приходит человек и начинает спрашивать вопросы которые в явном виде уже описаны в документе. Просто ему/ей лень читать.😔
Я большой поклонник Го, но очень настоятельно не рекомендую писать на Го shared library: рантайм Го может конфликтовать с рантаймом вызывающего языка (если конкретно - руби в моем случае) при увеличении стэка горутины. Возникает падение связанное с повреждением/порчей памяти.
Данная проблема известна довольно давно, но поскольку данное направление для разработчиков языка не является приоритетным - уже несколько лет остаётся не решенным. Мне не хватает времени для погружения в недра компилятора и создания соответствующего PR. Возможно кто-то, кому это критично сможет выделить ресурсы.
Если нужно вынести вычисления во что-то быстрое, то я бы порекомендовал использовать любые механизмы IPC (Unix sockets, напрямую stdin/stdout pipes, etc) и запускать модуль как отдельный подпроцесс. Или использовать языки с фиксированным стэком. В идеале вообще без рантайма. В крайнем случае - не использовать горутины в shared library.
Хорошая статья для обучения.
Еще есть http://nfpm.goreleaser.com/ где можно чуть упростить процесс
А можно пожалуйста по детальнее про встроенные секреты в nomad и consul?
Не сочтите за негатив, но в меня зацепила фраза про переход от swift к object-c, как только вы стали себя чувствовать более менее комфортно.
Если честно, то постоянно увеличивающийся разный объем данных которые нужно усвоить это абсолютно нормально для профессии (если не стагнировать). Мне кажется, вам очень повезло и вы по сути получили предварительный опыт работы в ИТ. Если это вводит вас в состояние неконтролируемого стресса, то я бы рекомендовал повторно поставить себя вопрос о необходимости входа в ИТ.
Принцип «плыви или тони» тут почти везде
Для Го порекомендую
если нужно много запросов и не хочется писать типы: SQLC https://github.com/sqlc-dev/sqlc
если хочется чего-то быстро прикрутить но с атомаперром и типами: микро обертку над sqlx https://github.com/reddec/gsql
OIDC прексрасная вещь, но все же не тривиальная. Недавно делал библиотеку и вместо проекта на один вечер, это вылилось в две недели каждый день по 4-5 часа после работы.
Клиентов много, каждый клиент представляет собой независимое вычислительное устройство. Гораздо дешевле поставить дешёвый сервер и переложить весь рендер на клиента тем самым массово и бесплатно распараллеливая обработку.
Во-вторых, при использовании SPA вы практически автоматом получаете и UI и API. Если точное - UI становится просто обёрткой над стандартным API. Не нужно дублировать работу и клиентам максимально удобно интегрироваться.
Последнее - backend становится полностью независимым от UI, может разрабатываться разными командами и на разных языках (в отличие от SSR с гидрацией, который обычно требует одной платформы - node, позволяя делать универсальный код и для сервера и для клиента).
Более того, хорошо написанный фронт будет работать быстро и потреблять мало место (chunk, lazy load, etc...). И полировать и релизить его можно не меняя сервер
Можно, пожалуйста, для непрофильных специалистов дать краткий обзор преимуществ и недостатков этого модуля?
At least once - точно доставит, но возможно больше одного раза
At most once - может доставит, может нет, но точно не более одного раза
Exactly once - точно доставит, и точно не более одного раза.
Для exactly once требуется хранить в том или ином виде состояние на клиенте: offset/ключи корреляци и тп. Самый дорогой вариант. Более того, для поддержки exactly once, требуется поддержка и отправителя и получателя
Вот одна из проблем, на которую я сам напоролся https://github.com/fyne-io/fyne/issues/2506
Fyne очень тяжелый. Я на него возлагал большие надежды, но на Линуксе и Маке более-менее реалистичное приложение (много экранов, уведомления, таблицы...) ест батарейку и память больше чем хорошо написанное приложение на электроне.
k3s лучший из "микро" версий кубера,но...
Спустя полгода мучений управления k3s я понял, что на небольших сетапах кубер просто не нужен и мешает (можно обойтись ансиблом или номадом), а на больших лучше сразу полноценный дистрибутив использовать.
Думаю тут есть нюанс с поставкой оборудования для ДЦ и как следствие ограничения для масштабирования
Соглашусь. Добавлю, что в сочетании с hugo и простейшим ci/cd получается отличная система хранения знаний для интранета
Если я правильно понял, можно использовать и в коммерческих компаниях, до тех пор пока не перепродаешь ZeroTier как сервис или услугу
ZeroTier открытый исходный код. Последняя версия в BSL, которая автоматически становится Apache 2 (через год кажется)
Небольшой отчет кому это может быть интересно. После этой наводки я поставил себе ZeroTier controller + zero-ui. Сначала нативно, потом без проблем перенёс в личный кубернетес.
Надо сказать товарищи из ZT сделали гигантскую работу по упрощению запуска контроллера. Все мои потребности закрывает на 100%.
Из положительных моментов, контроллер по умолчанию становится релеем (хотя в доке указано обратное). В локальной сети ZT автоматически устанавливает локальный маршрут.
Собственный контроллер кроме ощущение контроля даёт ещё и безлимитный объем сетей и подключенных узлов (да, у меня сетевых устройств больше чем бесплатный лимит).
Я склонен с вами согласиться, хотя и долгое время был поклонником tinc (даже статьи писал). Однако, я так и не нашёл аналогичную систему, которая умела бы автоматически пересылать трафик между узлами через посредников. Nebula , Tailscasle, ZeroTier полагаются во многом на пробив NATa, что не всегда возможно. TS, ZT хотя бы умеют использовать свои сервера при недоступности оконечных узлов, однако идея пускать траффик через сервера третьих лиц меня пугает.
Ещё бывают ситуации, что архитектуру детально прописываешь, согласовываешь, создаёшь RFC, рисуешь диаграммы разного уровня детализации, составляешь секцию FAQ, а потом приходит человек и начинает спрашивать вопросы которые в явном виде уже описаны в документе. Просто ему/ей лень читать.😔
Я большой поклонник Го, но очень настоятельно не рекомендую писать на Го shared library: рантайм Го может конфликтовать с рантаймом вызывающего языка (если конкретно - руби в моем случае) при увеличении стэка горутины. Возникает падение связанное с повреждением/порчей памяти.
Данная проблема известна довольно давно, но поскольку данное направление для разработчиков языка не является приоритетным - уже несколько лет остаётся не решенным. Мне не хватает времени для погружения в недра компилятора и создания соответствующего PR. Возможно кто-то, кому это критично сможет выделить ресурсы.
Если нужно вынести вычисления во что-то быстрое, то я бы порекомендовал использовать любые механизмы IPC (Unix sockets, напрямую stdin/stdout pipes, etc) и запускать модуль как отдельный подпроцесс. Или использовать языки с фиксированным стэком. В идеале вообще без рантайма. В крайнем случае - не использовать горутины в shared library.
Svelte может взять на себя обвязку (отслеживание свойств, стилизация и тп) и скомпилироваться в вебкомпонент. Как пример такого компонента: https://reddec.net/demo/github-card/ (исходный код https://github.com/reddec/github-card)