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

Эта часть будет немного отличаться от предыдущих. Я думаю мы немного обновим Go код и, тем самым, избавимся от возможных проблем с очисткой, которые я упоминал в прошлый раз. Как только закончим с этим, займемся версткой кода для создания расширения Chrome! И на этой ноте давайте начнем!

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

Цепочки Celery позволяют вам модульно оформить ваше приложение и повторно использовать общие задачи. Классическим примером использования является система рыночных данных.

И снова добро пожаловать! Если вы еще не забыли, в прошлый раз мы фактически добавили возможность загружать файлы. В этот раз будем отталкиваться от этого. Посмотрите, я добавил здесь только лишь один импорт и несколько строк, т.к далее они нам пригодятся, а в остальном большая часть базового кода в этой итерации останется прежней.

В прошлый раз мы остановились на том, что закончили собирать нашу конечную точку загрузки. В этот раз мы расширим наш проект, чтобы уже наконец-то попробовать загрузить файл. Все это означает, что мы также научимся тестировать конечную точку загрузки. Вы готовы? Давайте скорей погружаться!

В прошлый раз мы опеределились с планом создания простого сервера на Go, который бы загружал удаленные файлы. В этот раз я бы уже хотел приступить к написанию настоящего кода. Я постараюсь документировать все, что помогло мне собрать программу вместе со всеми ссылками, которые я использовал. Я также пытался ясно и понятно именовать переменные. Например, используя ответ http.ResponseWriter , запросите *http.Request вместо w http.ResponseWriter, r *http.Request. Надеюсь на то, что любой человек с любым опытом сможет разобраться в коде.

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

goRBAC  предоставляет довольно облегченную реализацию управления доступом (RBAC) по ролям в Голанге. Вся информация о привилегиях (роли, родители и разрешения), как правило,  сохраняется в постоянном хранилище, к примеру в базе данных, файлах или облачном хранилище. В этом посте мы с вами кратко обсудим, как загрузить экземпляр goRBAC из постоянного хранилища и как сохранить экземпляр обратно. Чтобы нам было проще, в качестве постоянного хранилища будем использовать файл JSON.

Пару месяцев назад я начал писать на Go так же известным, как Golang. И не только из-за их потрясающего логотипа. Основная причина была в том, что я хотел, чистую железяку на моем Raspberry Pi, а так же кроссплатформенность в паре с легкостью установки. Среди других причин были простота создания на Go асинхронного кода с помощью Go методов и уникальный подход к синхронизации каналов между подпрограммами (потоками) посредствам go routines.