Теперь пришло время хороших практик с API и данными (см. Часть 1 и часть 2). Когда вы впервые думаете о Meteor, вы можете забыть, что у вас есть API, потому что все просто работает, но это становится ясно, когда у вас есть ваше приложение опубликовано в Apple Store и Google Play, потому что, если вы не обращаете внимания, возможно, ваше приложение будет часто ломаться после обновления для ваших пользователей, пока Meteor не сможет обновить клиентский код.

В типичном приложении Meteor у нас есть две вещи, которые можно рассматривать как API: Публикации и Методы. Оба из них работают на стороне клиента вашего приложения без каких-либо подробностей конфигурации, детализирующих, где найти ваш сервер или IP-адреса, Meteor работает таким образом по дизайну, всегда стараясь быть как можно более простым для нас, разработчиков.

GP-3.1 Соберите все вместе свой код API

Когда вы работаете со своим кодом, очень легко заменить старую публикацию или метод, не замечая, что вы нарушаете работу своих текущих клиентов, это происходит просто потому, что с помощью Meteor легко создать новые конечные точки API. Чтобы избежать такого рода проблем, я всегда помещаю весь свой код API в папку / imports / api, обычно внутри этой папки у меня есть две папки: одна для публикаций, а другая - для методов. Когда мой код организован таким образом, я всегда могу дважды проверить свои изменения в коде API перед выпуском новой версии моего приложения. Я просто сравниваю свой новый тег git с предыдущим и сосредотачиваю свое внимание только на этой папке.

Любое изменение имен или входных данных этих ресурсов может привести к критическим ошибкам и потенциальным потерям пользователей. Но зачем нам вообще что-то менять? Давайте посмотрим на пустышку, у нас есть способ поставить лайк посту (этот фрагмент взят из приложения Cavadinha, посмотрите):

Теперь давайте подумаем, что нам нужно создать новый метод для лайков комментариев. Если вы назвали его как likeComment, у нас будут разные шаблоны имен между двумя очень похожими методами (один из них просто like, а другой - likeComment), тогда лучше подходит для likePost и likeComment, но это нарушит старые коды, пытающиеся лайкнуть сообщения с like вызовы методов. Если вы сосредоточите все в одной папке, мы, вероятно, заметим, что в нашем обзоре кода перед публикацией нового выпуска, а затем мы сможем исправить эту проблему, изменив наш код на этот:

С его помощью наша проблема решена, потому что мы какое-то время оставляли метод like доступным, и когда наше приложение будет выпущено Apple, мы сможем удалить старую версию Like.

GP-3.2 Проверьте вводимые данные API

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

Что ж, теперь давайте переключимся на данные. Снова в игру вступает простота Meteor, и время от времени это может мешать, может быть, вы только начинаете работать с Meteor и не до конца понимаете, как публикации и подписка работают с вашими данными, это хороший способ лучше понять это. Процесс заключается в том, чтобы заглянуть в Meteor DevTools на вкладках DDP Monitor и MiniMongo. Это нормально - не понимать полностью все о том, как работает Meteor вначале, но важно копаться со временем, и этот инструмент может вам помочь.

GP.3.3 Будь скромным

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

В этом контексте Будь скромным означает, что вы просто получаете данные, которые вам действительно нужны, в своем клиентском коде. Иногда это означает иметь более одной публикации для очень похожего предложения, но такова жизнь. Если это часто встречается в вашем приложении, возможно, лучше использовать GraphQL с Apollo вместо системы публикации / подсистемы Meteor по умолчанию, если вы думаете, что это действительно ваш случай, хорошая новость заключается в том, что Apollo тоже из MDG, тогда Вы продолжаете в хороших руках, и, конечно же, это очень хорошо работает с Meteor и даже с Blaze.

Иногда в процессе уменьшения объема передаваемых данных вы даже можете обнаружить, что ваша схема сбора не так хорошо спроектирована, как вы думали вначале. Возможно, вам нужно преобразовать несколько вложенных массивов с идентификаторами в новые коллекции. Я расскажу об этом подробнее в одном из следующих постов, следите за обновлениями (подписывайтесь на меня в Твиттере).

GP3.4 Создайте свои публикации

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

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

На сегодня все. Если у вас есть хорошие практики или вы не согласны с моими идеями, пожалуйста, оставьте комментарий и… ❤️