Node.js: зависимость и решение

TL;DR При использовании 1% библиотеки, возможно, стоит подумать о том, чтобы не использовать эту библиотеку.

Я начал писать (небрежно) ANSI C, компилировал с помощью GCC/GNU Make и запускал на каком-то дистрибутиве Linux (сначала Slackware, потом Ubuntu). Конечно, было время, когда я работал на Cygwin и работал на машине с Windows 98, но это было довольно недолго. В основном это был C в Linux. Почти все это было либо небольшими одноразовыми инструментами, либо какой-то формой текстовой приключенческой игры (одиночной или многопользовательской). В конце концов я переключился на нишевый язык LPC (теперь он называется Pike) и немного узнал об объектно-ориентированном программировании. По большей части я либо использовал стандартную библиотеку, либо писал в стандартизированной среде (такой как кодовая база MUD). Какое-то время я не очень понимал, что такое зависимости. Если бы что-то, например функция или набор поведений, не существовало, мне пришлось бы это создать. И это именно то, что я сделал. Снова и снова.

Над.

И.

Над.

Я полагаю, что написал по существу один и тот же сервер сокетов по крайней мере 12 раз (в конечном итоге на 3 разных языках).

Потом я открыл для себя Python. После этого я открыл для себя Node.

Python был первым языком, который я использовал, где я столкнулся с управлением пакетами. В какой-то момент я баловался Visual Basic, создавая инструменты, ориентированные на формы, в основном все еще предназначенные для того, чтобы утолить мой занудный игровой зуд; игра в кости, генератор листов персонажей AD&D 2nd Edition, трекер коллекции карт Magic: The Gathering и т. д. Ничего, что я бы назвал «серьезным», и уж точно ничего, что заставило бы меня отправиться в большой мир библиотек кода. Python изменил это, познакомив меня с pip. Мне казалось, что передо мной открывается целый новый мир, например, если раньше мне приходилось тратить дни или недели, чтобы «сделать это», то теперь я мог просто установить это, прочитать некоторые документы, а затем продолжить кодирование.

Даже тогда я использовал библиотеки довольно незначительно и в основном опирался на стандартный набор классов, методов и функций, доступных в Python. Перенесемся на несколько лет вперед, и я познакомился с Node и npm.

Я был очарован невероятным разнообразием библиотек или «модулей», которые существовали в экосистеме Node. Очень быстро я открыл для себя такие инструменты, как babel, grunt и yoman. Вскоре после этого я узнал о новом проекте под названием «Meteor.js», а вместе с ним и о еще одном, еще более полнофункциональном источнике модулей. Это придавало сил; Я чувствовал себя настолько продуктивным, как будто я мог взломать свой путь к чему угодно. Конечно, то, что я ожидал увидеть в «стандартной» библиотеке, было модулями, поддерживаемыми сообществом… но они работали, верно?

Это не история о ком-то, кто обжегся на leftpad и теперь делает все функциональные возможности из цельного куска ткани. Хотя я стою на своей мыльнице и время от времени проповедую евангелие стройных депсов, это происходит по несколько иной причине. Это связано не столько с простым фактом импорта долга в вашу кодовую базу (хотя это часть моих чувств), сколько с осознанием того, что вы создаете и для чего.

К вопросу о размере пакета…

Пример, который я видел не раз в последнее время, связан с библиотеками HTTP-запросов. В частности, библиотека Axios часто используется для простых запросов GET и POST. Лично я использовал Fetch API через что-то вроде node-fetch в течение достаточно долгого времени, и меня интересовал Axios и какие преимущества были достигнуты при его использовании по сравнению с полиморфным API-интерфейсом «следующего поколения».

На первый взгляд кажется, что Axios предоставляет знакомую поверхность API, указав URL-адрес и некоторые параметры, такие как метод, заголовки и так далее. Глядя немного глубже, кажется, что он поддерживает некоторые более продвинутые функции, такие как одновременный контроль обещаний и отменяемые запросы, аналогичные суперагенту. Это некоторые мощные помощники, которые могут сэкономить вам время и усилия, возможно, совсем немного.

Но все же… все, что я вижу, это случайные GET и POST… ни параллелизма, ни отмены… ничего особенного.

Итак, каков относительный вес Axios по сравнению с моей переходной выборкой узлов? Bundlephobia выдает для обоих пакетов следующий вывод:

Похоже, в весе этих библиотек есть довольно существенная разница. Имеет ли смысл использовать Axios вместо node-fetch для простых запросов, таких как отправка POST в API? Оправдывает ли сахар калорийность?

¯\_(ツ)_/¯

Это не мне говорить; каждый проект отличается, и предпочтения каждого разработчика и оценка компромиссов различны. Грубо говоря, ядро ​​Node включает в себя средства для создания запросов, которые прекрасно работают. Означает ли это, что вам следует избегать библиотек, которые уменьшают количество шаблонов или увеличивают радость разработчиков в обмен на небольшой размер кода? Скорее всего нет. Для меня это приводит к размышлениям о том, действительно ли мне нужно все это… или какой-то крошечный уголок.

Еще один отличный пример, с которым я недавно столкнулся, — это проверка схемы JSON. Две библиотеки, обе из которых достигают одного и того же результата с разным относительным весом; действительно и да:

В этом случае поверхность API между двумя библиотеками сильно различается, независимо от того, служат ли они одной и той же цели. Один лучше другого? Ну, это вопрос мнения и приоритетов ;)

Настоящая проблема для меня сводится к «почему».

Что такого в этой конкретной библиотеке, которую я использую? Почему я его использую? Когда я почувствую, что смогу использовать более полный набор функций, предоставляемых библиотекой? Буду ли я когда-нибудь? Могу ли я чему-то научиться, реализовав этот маленький уголок модуля самостоятельно? Могу ли я сделать это по-другому? Может быть лучше?

Часто ответ, который я придумываю, гораздо менее удовлетворителен, чем я надеялся, как правило, какое-то смутное ощущение «не наследования долга» как хорошего решения для моей кодовой базы. Скорее всего, это действительно правильный выбор. Например, так ли хорош мой менеджер с крошечным состоянием, как Redux? Нет, но он будет управлять состоянием, и все это можно будет понять за 2–10 секунд. Есть хороший шанс, что я уменьшил «когнитивные накладные расходы», которые понесут мои коллеги, используя мою маленькую служебную библиотеку вместо какой-то невероятно мощной… и самоуверенной альтернативы.

Будет ли он таким же мощным?

No.

Это более низкий риск?

Может быть.

Я чему-то научился?

Абсолютно… даже если время от времени я узнаю, что мне не следует писать клиентские оболочки БД для людей (смеется… извините, Рео Шибацудзи и Кэлвин Хси… я должен только что использовал прокси…)