Как бы вы реализовали эту часть с помощью while и без мутирования массива? Граф зависимостей (очередь) должен включать все модули приложения, которые можно определить только при переборе зависимостей каждого модуля. Кроме того, необходимо определить не только модули, но и связи между ними.
Для этого используется стек и рекурсия. Больше вопросов вызывает разрешение конфликтов: способ, приведенный в статье, это хак, который может работать не во всех случаях.
Я бы сказал, что Express и Socket.io не отвратительный, а, скорее, классический, хотя, возможно, и не лучший выбор. Про Fastify и uWebsockets слышал, но ни то, ни другое пока не пробовал. Сейчас знакомлюсь с Nest.js, в котором в качестве нижележащей платформы (underlying platform) по умолчанию используется Express, хотя имеется возможность переключиться на Fastify. Вероятно, Express все-таки не так страшен, как его малюют. Впрочем, возможность переключения на Fastify тоже кое о чем говорит.
Спасибо за комментарий. Вот что удалось выяснить: 1) метод captureStream не поддерживается в Safari; 2) в Firefox он поддерживается с префиксом, т.е. вместо captureStream следует использовать mozCaptureStream. Внес необходимые правки в статью, репозиторий и песочницу.
swagger-autogen многое умеет определять автоматически (конечные точки, параметры и тела запросов в общем виде, статус-коды ответов и т.д.). Понятно, что чем более подробное описание, тем сильнее оно подвержено устареванию (потому что подробное описание делается вручную). Вероятно, на этапе активной разработки приложения основное внимание следует уделять поддержанию в актуальном состоянии хотя бы основного описания с помощью doc (модели, операции и т.п.), а подробными комментариями снабжать только относительно стабильные роуты
Хорошо, реализуйте эту часть с помощью while, и увидите, что результат тот же, а кода больше.
Как бы вы реализовали эту часть с помощью while и без мутирования массива? Граф зависимостей (очередь) должен включать все модули приложения, которые можно определить только при переборе зависимостей каждого модуля. Кроме того, необходимо определить не только модули, но и связи между ними.
Спасибо, друг.
Для этого используется стек и рекурсия. Больше вопросов вызывает разрешение конфликтов: способ, приведенный в статье, это хак, который может работать не во всех случаях.
Спасибо за дополнения.
Согласен, поправил.
Спасибо за дополнение
Руководство по Workbox: https://github.com/harryheman/React-Total/blob/main/md/wb/wb.md. Пример кеширования статики с помощью СВ при его установке: https://github.com/harryheman/Modern-HTML-Starter-Template/blob/main/service-worker.js
Imgproxy, к сожалению, не мой. Вот его разработчик: https://github.com/DarthSim
Сохранение файлов на диске и их последующее использование без запроса к imgproxy похоже на кеширование.
Честно говоря, не знаю, полистайте доку: https://docs.imgproxy.net/
Я бы сказал, что Express и Socket.io не отвратительный, а, скорее, классический, хотя, возможно, и не лучший выбор. Про Fastify и uWebsockets слышал, но ни то, ни другое пока не пробовал. Сейчас знакомлюсь с Nest.js, в котором в качестве нижележащей платформы (underlying platform) по умолчанию используется Express, хотя имеется возможность переключиться на Fastify. Вероятно, Express все-таки не так страшен, как его малюют. Впрочем, возможность переключения на Fastify тоже кое о чем говорит.
Спасибо за комментарий и дополнение
Спасибо за подборку
Спасибо за комментарий. Вот что удалось выяснить: 1) метод captureStream не поддерживается в Safari; 2) в Firefox он поддерживается с префиксом, т.е. вместо captureStream следует использовать mozCaptureStream. Внес необходимые правки в статью, репозиторий и песочницу.
Какой браузер?
из песочницы
Спасибо. Постараюсь
swagger-autogen многое умеет определять автоматически (конечные точки, параметры и тела запросов в общем виде, статус-коды ответов и т.д.). Понятно, что чем более подробное описание, тем сильнее оно подвержено устареванию (потому что подробное описание делается вручную). Вероятно, на этапе активной разработки приложения основное внимание следует уделять поддержанию в актуальном состоянии хотя бы основного описания с помощью doc (модели, операции и т.п.), а подробными комментариями снабжать только относительно стабильные роуты
Не за что. Спецификация комментариев, как вы это называете, имеется в документации к swagger-autogen, начиная отсюда: https://github.com/davibaltar/swagger-autogen#endpoints
Не за что