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

Наследование директив в nginx - это классная штука. Именно наследование позволяет писать простые и понятные конфиги. При слиянии конфигураций значение директивы и её функциональность переходит из вышестоящего контекста в текущий. Логично, что наследование не происходит от параллельных контекстов, например от соседнего location или if.

Вроде бы всё хорошо. Пока не возникают исключения.

N.B.: Здесь и далее описывается работа с nginx версии 1.21.1 (если не указано иное). Всё сказанное основывается лишь на опыте и ошибках автора. Вместе с тем автор не является разработчиком nginx и даже его маститым сварщиком, поэтому не стоит принимать слова автора как догму, а, наоборот, подвергать сомнению и самостоятельному тестированию.

Недавно мы собирали динамический модуль для Nginx, а когда всё было уже готово, то выяснилось, что наш модуль оказался не совместимым с Nginx, который уже был установлен на сервере. Готового решения возникшей проблемы нам найти не удалось и мы начали бороться с ней самостоятельно. Мы потратили много времени, но получили новый опыт и, самое главное, работающее решение. Которым и хотелось бы поделиться.

Начнём с описания процесса сборки динамического модуля на примере https://github.com/vozlt/nginx-module-vts. А затем покажем какая возникает ошибка и что с ней делать.

Уже довольно давно, вдохновившись статьей Ресайз изображений на лету был настроен ресайз изображений с помощью ngx_http_image_filter_module и все работало как надо. Но появилась одна проблема, когда менеджеру понадобилось получать изображения с точными размерами для заливки на некоторые сервисы, т.к. это были их технические требования. К примеру, если мы имеем оригинал изображения размером 1200x1200, и при ресайзе мы пишем что-то вроде ?resize=600x400, то получим пропорционально уменьшенное изображение по наименьшему краю, размером 400x400. Так же невозможно получить изображение с бОльшим разрешением (upscale). Т.е. ?resize=1500x1500 вернет все тоже изображение 1200x1200

На помощь пришла статья OpenResty: превращаем NGINX в полноценный сервер приложений для понимания как работает Nginx с Lua и сама библиотека для Lua isage/lua-imagick — Lua pure-c bindings to ImageMagick. Почему было выбрано такое решение, а не, скажем, что-нибудь на python — потому что это быстро и удобно. Вам даже не понадобится создавать никаких файлов, все прямо в конфиге Nginx (не обязательно).

Будущее веб архитектуры  программного обеспечения уже обретает формы и на этот раз server-side рендеринг (опять). Но есть кое-что новое,  а именно передача HTML по WebSocket.

Подход с использованием SPA(Single Page Appllication) и JSON API привел к тому, что многие команды разработки погрязли в бесконечных спорах о структуре данных и ошибках синхронизации между этими двумя слоями. Это увеличивает стоимость разработки, замедляет релизный цикл и сокращает время, которое можно было бы потратить на инновации.

Конечно же, после смерти Flash веб не превратился в простую, скучную плоскость. К старту курса по фронтенду показываем, как при помощи Three.js и технологии WebGL создать магический шар с анимацией внутри объёма. Автор статьи не только опубликовал код на CodePen для удобной демонстрации, но и добавил на страницу ползунки, чтобы вы могли экспериментировать с шаром и сразу видеть результат. В конце вы найдёте ссылку на исходный код на Github и демонстрацию не на CodePen.

Привет Хабр!

Когда я гуглил эту тему, я планировал выпустить только видео для плейлиста о Паттернах. Но как то мне не очень понравились уже существующие статьи, возможно потому что я пишу на JS, а там примеры были, то на python, то еще на каком языке. Поэтому я решил опубликовать свое видение темы Программируйте на уровне интерфейсов. Возможно это будет кому-то полезным (Данная статья является расшифровкой видео).

Хабру катастрофически не хватает такого формата постов как "продолжение" или "дополнение". После написания статьи зачастую появляется материал, который хотелось бы добавить к сказанному, но update'ить статью, с её сроком жизни в 1-2 дня, бессмысленно, а писать в комментариях невозможно из-за объёма материала. В то же время этого материала может быть недостаточно для новой статьи, да и, в силу того, что он сильно перекликается с предыдущей статьёй, придется либо постоянно её цитировать, либо оставлять пробелы, подразумевая, что читатель понимает о чем идет речь.

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

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

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

При этом, даже если модуль давно написан и имеет хорошие отзывы, нет никакой гарантии, что его работа не вызовет проблем, причем, возможно, исключительно в нашей конфигурации или сборке. А Nginx, как известно, рождён для производительности, и, добавляя модули, мы не хотим этой производительности потерять. Поэтому каждая новая сборка должна завершаться отладкой и профилированием.

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

Привет, меня зовут Сергей и я фронтендер в KTS.

Server Side Rendering часто применяется в разных проектах. Существуют крутые фреймворки для React – NextJS и Gatsby. Но в то же время любой фреймворк диктует архитектуру приложения, а это приводит к проблемам в больших приложениях. Поэтому часто можно встретить собственные сборки для SSR.

В статье описаны шаги создания собственной библиотеки для серверного рендеринга на React.

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

Теория

Ресурс работы SSD накопителя теоретически не ограничен, если не превышать количество циклов перезаписи в ячейку.

Задача

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

Выбор железок дело субъективное, но для себя сформулировал требование к малому формфактору. Кроме того все что скрыто от глаз в квартире, как правило лежит в пожароопасном месте, по этому хотелось питание в по USB, и минимум проводов.

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Введение

Зашел тут на Хабр и нашел в черновиках не опубликованную статью про капчу, хотел было её оформить и опубликовать, но решил написать новую статью немного поменяв механизм и используемый инструментарий. Старую статью по моему мнению будет полезно почитать, хуже не будет.

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