Результати пошуку за запитом: mvc4 5*
10 корисних фіч, про які ви могли не знати
Автор: Angular Guru
10 полезных фич в Angular, о которых вы могли не знать
Angular - это объемный фреймворк, и наверняка большинство из нас использует лишь небольшую его часть. Но за этим мы можем упускать некоторые весьма полезные его возможности, которые сделали бы нашу жизнь значительно проще. В этой статье я собираюсь разобрать около 12 полезных фич в Angular, о которых вы могли и не слышать.
Одна из вещей, о которой часто забывают, но которая таит в себе множество полезностей, является Pipe. Итак, давайте поговорим о них.
KeyValuePipe
Это одна из ключевых особенностей Angular 6.1. До этого все, что позволяла директива *ngFor, так это проитерировать массив или другую счисляемую конструкцию. Что же в случае со свойствами объектов или элементов Map - перебрать их было задачей отнюдь нетривиальной.
Это как раз тот случай, когда может пригодиться директива KeyValuePipe! Мы просто ставим pipe по отношению к объекту, который желаем проитерировать, и все остальное за нас совершает ngFor. К примеру:
Slice Pipe
Отображение списка предметов и манипуляция большим объемом DOM-элементов - задача достаточно затратная, потому порой могут возникать ситуации, когда мы захотим уменьшить количество отображаемых элементов. Выполнить это можно многими способами, но Angular обладает прекрасным SlicePipe, который позволяет нам выполнить все это всего лишь как часть нашего ngFor - выражения.
К примеру, давайте представим, что мы хотим отобразить только первые 10 элементов массива:
Decimal Pipe
Этот pipe предназначен для форматирования чисел. Он может быть весьма полезен, когда мы желаем ограничить число цифр, которые будут показаны после точки. Впрочем, он также может быть использован, когда мы просто желаем представить определенное число в более "презентабельном" виде, с запятыми после каждой тысячи. Так, 1000 у нас станет 1,000.
Кроме того, стоит также упомянуть еще об одной полезной фиче здесь. А именно, функции formatNumber, которая является частью @angular/common, что позволяет применять то же самое форматирование на программном уровне.
JSON Pipe
Крайне полезный инструмент, особенно при отладке. Позволяет вам отобразить объект в виде строки в представлении. Подобный подход может стать неплохой альтернативой точкам остановки и командам отладчика в некоторых случаях.
Просто добавьте JSON pipe объекту, который вы желаете отобразить:
Заголовок и мета-сервисы
Становятся особенно полезными, когда мы работаем с поисковиками или соц. сетями (по типу Google, Twitter, Facebook и т.д.). Эти платформы для формирования контента, названия, его описания используют теги <meta>.
К примеру, в нашем блоге для каждой статьи существуют свои заголовки, описания, картинки и так далее. Дабы убедиться в достоверности предоставляемой информации, мы можем поместить все необходимое в специальные мета-теги, как показано на примере ниже:
Плюс у нас есть сервис Title, который, как вы понимаете, обновляет заголовок, отображаемый в окне браузера. Достичь этого можно просто и незамысловато: просто добавить значение тегу <title> в заголовке документа. Впрочем, здесь, увы, мы не сможем использовать стандартную Angular-привязку: <title>{{ myTitle }}</title>, так как <head> не находится внутри Angular-компонента. Поэтому здесь мы должны использовать сервис Title. Использовать его очень просто:
Дабы позволить социальным сетям обнаружить эти мета-теги, они должны быть представлены на странице в момент ее загрузки (без использования JavaScript).
ng-container
Пытались ли вы когда-либо поместить две структурные команды на один и тот же элемент, впоследствии обнаружив, что вы не можете это сделать?
Или, возможно, вы применяете при этом ngTemplateOutlet, отмечая, что сие не позволяет в качестве дочернего, а лишь как родственный?
Согласны, это может быть весьма утомительно, особенно если единственный способ решить сей ребус - добавить обертку в виде <div>, что, безусловно, может "замусорить" существующую DOM-структуру.
К счастью, существует ng-container, что позволит вам избежать подобных проблем. Этот элемент, доступный при разработке, на самом деле не создает никаких новых элементов в структуре DOM-дерева и может быть прекрасным решением для обеих вышеназванных ошибок и даже более!
К примеру, дабы использовать несколько структурных деректив, мы может просто сделать следующее:
После чего просто применить существующий темплейт в качестве дочернего:
Это лишь малая часть возможных применений сего инструмента, уверяю вас, при желании ng-container можно использовать и для более широкого круга задач.
Декоратор атрибутов
Все мы знаем, что свойства-декораторы @Input и @Output используются для привязки и порождения событий. Впрочем, существует другой, менее известный декоратор, @Attribute.
Этот декоратор чем-то похож на @Input-декоратор, так как он может быть использован для передачи значения компоненту.
Привязка атрибута чем-то похожа на scope-привязку AngularJS:
Для начала, давайте изучим ограничения декоратора!
- Любые значения должны быть представлены строковым типом данных
- Значения статические и не изменяются, в отличие от привязок
- Мы не можем использовать синтаксис привязки [attribute]
В то время, как существуют определенные незначительные ограничения, выигрыш от повышенной производительности будет более значимым.
Они могут быть использованы точно так же, как и @Input-декоратор:
Мониторинг изменений профиля
Я уверен, все мы знаем о функции enableProdMode, что будет вызвана в main.ts-файле любого проекта Angular CLI. Впрочем, здесь также существует функция enableDebugMode. Конечно, мы можем думать, что, мол, если я не работаю в прод-режиме, значит, я работаю в режиме отладки, но, кхм, все не совсем так.
Вызывая эту функцию, мы получаем дополнительный инструмент - window.ng объект, что называют профилировщиком. Профилировщик имеет в своем арсенале функцию timeChangeDetection, при вызове которой выводится консольная информация о том, сколько произошло change-detection - циклов (а также о том, сколько времени они заняли).
Может быть очень полезно при профилировании приложений с низкой производительностью. Для вызова функции добавьте следующее в коде bootstrap:
Для запуска профилирования, введите в DevConsole следующее:
NgPlural
Во многих приложениях бывают случаи, когда необходимо описать определенное число элементов, и в рамках нашего приложения нам нужно предусматривать различные ситуации. К примеру, рассмотрим следующие варианты:
- Предметов нет вообще
- Есть только один предмет
- Есть только два предмета
Директива же ngPlural очень проста в использовании, и предназначена она для обработки подобных случаев:
ngPreserverWhitespaces & NgNonBindable
Я решил сгруппировать две эти директивы, так как используются они в принципе в схожих условиях.
В Angular 5 существовала опция preserveWhitespaces, добавленная в angularCompilerOptions. Если бы ее значение было равно false, оно бы позволило компилятору избавиться от пробелов, которые не считались существенными. Конечно, читабельность могла бы пострадать, но, с другой стороны, это позволило бы уменьшить размер пакета.
Впрочем, бывают случаи, когда мы желаем сохранить пробелы. Если мы хотим оставить целый компонент нетронутым, нам необходимо просто использовать опцию в декораторе компонента:
Впрочем, мы также можем желать оставить нетронутым пробел в определенном DOM-элементе. В таком случае мы можем использовать директиву ngPreserveWhitespaces.
Также мы можем использовать {{ }} в нашем документе, впрочем, в любом случае Angular сочтет это за использование интерполяции и попытается оценить, что находится внутри ее. В таком случае нам придется кстати ngNonBindable.
Ну, вот и все! Здесь были описаны 10 вещей, которые вы могли не знать об Angular. Надеюсь, вы найдете их полезными!
Автор перевода: Евгений Лукашук
Источник
Позбавляємося "запаху" в коді
Автор: Dino Esposito
Каков Ваш код на... запах?
Как люди мы имеем огромное количество различных желез на теле. Как у программистов у нас есть множество строчек кода в проектах. Как у людей некоторые наши железы выделяют запах - хороший или не очень. Как у программистов некоторые наши строчки кода также могут иметь своеобразный "запашок". В мире программирования "запашок" недопустим.
Подобно тому, как неприятный запах может свидетельствовать о различных медицинских проблемах организма, плохо организованный код также может быть симптомом плохо построенной архитектуры приложения. Итак, должны ли мы беспокоиться при наличии "запаха" у нашего кода?
"Запах" кода - это не то же самое, что и баг. Если коротко, "запах" кода - это та ситуация, когда вроде бы нам не очень нравится код, который мы написали, но не так, чтобы его исправлять или переписывать... Это как раз таки фатальная ошибка.
Рост кода подобен по своей природе росту дерева. Отсекание некошерных веток важно, чтобы дерево оставалось в добром здравии. Если этого не делать, ветки становятся все длиннее и длиннее - и, как следствие, процесс сбора плодов также становится затруднительным. Без рефакторинга поддержка кода может стать затратным вложением.
Дурной запах кода усложняет поддержку, так как любой код требует поддержки. Вообще, "запах" кода был классифицирован в зависимости от сценария, который он представляет.
Эта статья - краткий взгляд на различные виды несовершенств кода, чтобы мы могли понять, на что стоит обратить внимание в разрабатываемых продуктах. И давайте быть честными по отношению хотя бы к самим себе: если не сейчас, то никогда.
Что же, начнем!
"Дух" плохих методов
Первое, на что стоит обратить свое пристальное внимание, - это название метода. Также не стоит забывать и о названиях и общей длине параметров. Вот типичный "идеальный" метод:
Название четкое и ясное
Не длиннее 30 строчек и принимает не более 5 параметров
Реализация - простейшая из возможных, нет "мертвого" кода
Здесь представлен список возможных несовершенств:
Название
Описание
1
Мертвый код
метод не используется.
2
Ленивый объект
метод делает очень мало работы.
3
Посредник
все, что делает этот метод, - это вызывает другой метод.
4
Божественный метод
метод исполняет слишком много обязанностей.
5
Длинный список параметров
не забываем про рекомендацию в 5 параметров.
6
Перекрученная сложность
слишком сложная реализация простых операций.
7
Цикличный ад
злоупотребление циклами и условными конструкциями.
8
Излишняя близость
метод очень сильно зависит от особенностей реализации другого метода.
9
Завистливый объект
метод полагается на данные другого объекта больше, чем на свои.
10
Черная овечка
метод сильно отличается от других методов класса.
"Запашок" класса
Проверяйте название класса и то, насколько реализуемый классом контракт отвечает его сути. Как правило, идеальный класс прекрасно отображает назначение различных сущностей на уровне бизнес-логики и реализует ее в рамках архитектуры, выбранной для самой бизнес-логики.
Вот список возможных несовершенств, связанных с классом:
Название
Описание
1
Ленивый объект
класс выполняет слишком мало работы.
2
Посредник
класс ничего не делает, просто вызывает объекты другого класса.
3
Божественный объект
класс слишком много о себе возомнил. Реализует слишком много операций.
4
Узколобое мышление
слишком примитивная реализация типов с особым назначением.
5
Шпион на допросе
реализуемый классом интерфейс не сообщает достаточное количество информации, чтобы понять назначение объекта.
6
Эксгибиционист
необязательное раскрытие внутренних деталей реализации.
7
Излишняя близость
класс слишком сильно зависит от реализации объектов, на которые он ссылается.
8
Жадинка
класс наследует поведения объекта, тогда как на самом деле классу нужны лишь некоторые его фрагменты.
9
Неопределенность
разработка класса становится слишком сложной из-за вороха фич, которые "когда-то" будут доведены до ума.
10
Непостоянство
класс содержит член данных, не характерный для всего времени жизни объекта.
Общее впечатление о коде
Рассматривая более высокий уровень абстракции, стоит также упомянуть несколько немаловажных аспектов:
Название
Описание
1
Утраченный смысл
код не совсем точно реализует требуемую от него задачу.
2
Выбирай, что хочешь
та же самая проблема уже решена - причем несколькими способами.
3
Комбинаторный взрыв
различные участки кода делают одно и то же, но с разным набором параметров.
4
Не копируй себя
много идентичного кода.
5
Сложность
слишком сложная реализация простых вещей.
6
Размазня
нет единого глобального класса. Ответственность размазана по целому вороху промежуточных классов.
7
Подводный айсберг
изменения внешне не связанных компонентов затрагивают слишком много вещей.
8
Спагетти-код
изменение одного компонента требует множество мелких изменений в других местах.
9
Пиар-комментарии
классные комментарии в плохом коде.
10
Информационный комок
группа переменных почти всегда передается вместе.
Стоит также уделить минутку своего внимания комментариям в коде. В то время, как комментирование назначения метода будет полезным для всех, кто читает его, комментирование реализации метода - достаточно спорное решение. Риск состоит в том, что по неосторожности можно использовать упомянутые "пиар-комментарии" к тем строчкам, которые этого отнюдь не заслуживают.
Отличный код таков, что нуждается в малом количестве комментариев, так как его реализация становится понятной интуитивно. Комментарии стоит использовать, когда мы комментируем особенности технических решений, вещи, оставленные для рассуждения или будущие этапы разработки.
Как бы это странно ни прозвучало, но комментарии никогда не должны рассматриваться в качестве обязательных для написания. Также не стоит забывать о различных тестах (в особенности о тех, которые не пишутся просто для повышения процента покрытия кода).
Стереотипы
Конечно же, куда без них. Кто-то может утверждать, что подобные тонкости коддинга начали выделять с прогрессом информационной индустрии. Мол, "запашок" кода очень часто является следствием "плохих привычек" написания или же в силу определенных обстоятельств. Подобные оправдания звучат несколько неубедительно и говорят о тараканах в голове разработчика: каждый уважающий себя программист должен стараться писать хороший код абсолютно всегда. По умолчанию!
Другой стереотип, о котором также стоило бы упомянуть, - это избыточная вера в рефакторинг. Что же, рефакторинг как процедура переписывания кода также может быть выполнен из рук вон плохо. Излишняя цикличность, слишком сложные решения и прочее-прочее запросто может быть добавлено в проект из лучших побуждений - особенно в том случае, если по принципу организации исходный код не сильно отличается от здорового клубка спагетти.
В итоге все разработчики могут "запачкать" свой код. Что хуже, часто это бывает под давлением внешних обстоятельств, особенно у "временных" разработчиков для хотфиксов. Проверки качества кода должны происходить всегда сразу после быстрых релизов.
И в заключение
Большинство из тех проблем, с которыми мы сталкиваемся, часто связаны с логическим промежутком, пропастью между уровнем абстракции выбранного языка программирования и языком бизнеса. Чем больше нам удается отстранится от "самовыражения" посредством языка программирования к бизнес-целесообразности, тем более читабельным и поддерживаемым будет наш код.
Гранулярность, модульность, разделение задач и все те прекрасные теоретические концепции, о которых мы могли слышать до этого, становятся конкретными и вещественными, когда мы загораемся желанием следовать концепции делового прагматизма и утилитарности.
Источник
Переводчик: Евгений Лукашук
ITVDN для корпоративних клієнтів Інтерв'ю із Дмитром Охріменком.
Автор: Редакция ITVDN
Дмитрий Охрименко – один из создателей ITVDN, автор видео курсов, консультант по построению распределенных и веб-ориентированных приложений, сертифицированный специалист Microsoft (MCTS, MCPD, MCT). Более 10 лет Дмитрий проводит корпоративные тренинги для IT специалистов в таких компаниях как 3Shape, GlobaLogic, Ciklum, Terrasoft, Simcorp и других.
Мы попросили Дмитрия ответить на ряд вопросов, связанных с обучением IT специалистов и о том, в какой мере ITVDN может помочь в решении этих задач.
Как HR-специалисту узнать, какие новые технологии нужно изучить разработчику?
Для этого есть много инструментов, которыми можно воспользоваться для определения действительно важных для разработчика тем. Так как бизнес должен зарабатывать деньги, то неправильно будет идти только на поводу у разработчика. Если говорить о мотивации, то все люди любят платить деньги за то, что приносит пользу, либо за то, что приносит удовольствие. Если брать разработчиков, то пользу им приносит все то, что может помочь в решении их повседневных задач. Если компания, например, разрабатывает какие-то веб-приложения, то, возможно, стоит обратить внимание на изучение их популярных библиотек, которые используются в проектах, на изучение разработки BackEnd-части. Это то, что можно отнести к пользе, которую получит разработчик. Если говорить об удовольствии, то все разработчики любят говорить, что они знают все самые последние технологии, что они имели опыт с последними версиями: C#, JavaScript, C++ и т.д. Поэтому мотивация может заключаться в том, чтобы проводить обучение, может, не совсем полезное для проекта, но зато - это новые технологии, и разработчик будет чувствовать себя частью передовых технологий.
Также необходимо проводить обучение для поднятия общего уровня знаний специалистов в проекте. По сути, как узнать, что нужно разработчикам? Лучше всего на этот вопрос ответит не сам разработчик, а тимлид или человек, который занимается организацией всей команды. Потому что четко понятно, что у этих ребят не хватает опыта работы с таким-то языком, инструментом и необходимо подтянуть именно эти навыки.
Можно сделать, например, общий опросник для всех разработчиков и узнать, что они хотят. Как показывает практика, это обычно разбросанные требования: хочу учить С#, хотя человек пишет на Java, или хочу учить Python, хотя в проекте он не будет вообще использоваться.
Для того, чтобы обучение мотивировало разработчиков и было полезно для самой компании, то HR-специалисту нужно собрать информацию не только от конкретных разработчиков, а еще и уточнить, что действительно необходимо для реализации тех задач, которые стоят перед командой в целом. Чтобы команда смогла поставить действительно качественный продукт.
Как происходит процесс построения корпоративного тренинга?
Чаще всего компания понимает, что ей не хватает каких-то знаний в определенных направлениях. По своему опыту, если возникает какая-то задача у HR-специалиста или у тимлида, что команду нужно подтянуть по знаниям, например, по JavaScript, то мы просто приезжаем от Учебного центра CyberBionic Systematics и предоставляем перечень тех курсов и материалов, которые уже существуют. Если компании необходимо подготовить, допустим, Frontend-разработчиков, то мы приезжаем с теми наработками, которые уже есть. Также предварительно готовим конкретное предложение, если от компании уже поступили рекомендации, что, например, нужно сделать больший акцент на объектно-ориентированное программирование, на библиотеку, на определенные инструменты. То есть, мы подготавливаем предложение таким образом, чтобы высветлить те проблемы, которые возникают перед разработчиками и дополнительно добавляем какие-то материалы, которые могут поспособствовать дальнейшему росту специалистов.
Мы проводим встречу с компетентными лицами. Собираемся с тимлидерами, с senior-разработчиками, они высказывают свои пожелания, они корректируют эту программу, и мы берем время на доработку дополнительных материалов. У нас очень много опыта по работе с киевскими компаниями. Очень часто компания Terrasoft заказывала именно абсолютно новую, индивидуальную программу. Они смотрели на то, что у нас есть, но вносили корректировки, которые требовали разработки 30-40 часов, под свои проекты.
Чтобы обучение было действительно качественным и эффективным, чтобы компания получила из этого выгоду, специалистам компании необходимо озвучить, какие проблемы есть и в каком направлении нужно учить команду. В большинстве случаев тимлид и senior-разработчик понимают, что у его 10-ти мидлов, джуниоров и других специалистов не хватает опыта в определенных заданиях. Обычно это знания выборочные и их нужно подтянуть, или их просто нет, тогда нужно донести до слушателей.
Наша задача понять, чего не хватает для того, чтобы специалисты были действительно продуктивными, и их работа была результативная. Для этого нужно подготовить программу, которая принесет пользу компании и специалисты будут удовлетворены. Мы расскажем им, что нужно знать и как нужно работать. Задачи компании будут решатся, а рабочих проблем должно стать меньше после того, как тренинг успешно закончится.
Какие формы обучения наиболее подходят для IT-специалиста?
Чтобы обучение было максимально эффективным, я думаю, его необходимо комбинировать. Использовать обучение вместе с тренером, когда он будет своим примером мотивировать разработчика, заставлять что-то новое учить и двигаться дальше. Также комбинировать обучение необходимо с добавлением онлайн-составляющих, дополнительной литературы. Если брать корпоративное обучение, то максимально эффективное будет очное и онлайн, когда приезжает тренер или обучает через скайп и подобные ресурсы. Непосредственно взаимодействуют все группы слушателей и дополнительно к этому добавляется обучение в видеоформате.
Для большинства проектов не всегда есть возможность оторвать людей от производственного процесса, есть определенные часы, в которые тренеру можно пообщаться с коллективом, рассказать теоретическую часть, но не всегда у разработчиков есть возможность полностью переключиться на подобного рода обучение. Обучения, когда в течение 5 дней в неделю по 5 часов учат определенную технологию, я считаю не очень эффективным, потому что информации очень много, не хватает времени, чтобы её освоить и закрепить. Я считаю, что обучение должно быть постоянным, интенсивным, но при этом в меру, чтобы была возможность переварить саму информацию.
Чтобы был максимальный эффект, необходимо комбинировать очное и онлайн-обучение, когда тренер рассказывает материал и добавлять видеоформат обучения. Конечно, в идеале было бы перевести все на видеоформат и сделать так, чтобы слушатели только смотрели видеоматериалы, но у многих часто возникают вопросы.
Если брать, например, проект ITVDN, то корпоративное обучение подразумевает еще и консультации, то есть команда может взять себе набор видеоуроков.
Создатели и авторы курсов ITVDN хорошо понимают, что именно и в какой последовательности учить и какой эффект будет максимально достигнут. Мы можем составить индивидуальную программу, сделать временные метки и консультировать команду уже по ходу обучения, чтобы они смотрели все в видеоформате и не отрывались от рабочего процесса, при этом мы будем проверять результаты тестирования и отвечать на возникшие вопросы в ходе обучения.
Мы открыты для диалога с компаниями, которые хотят мотивировать своих разработчиков и организовывать для них обучение. Наша команда готова разрабатывать индивидуальные программы, создавать индивидуальный график и подход к каждой компании в отдельности. У каждой компании свои собственные бизнес-процессы, своя корпоративная культура и всех под одну гребенку поставить не выйдет, поэтому мы готовы свои процессы подстроить под график конкретной организации.
Как ты посоветуешь "расшаривать" знания, делиться опытом внутри команды?
Я считаю, что лучшего всего организовывать мастер-классы, когда сама команда для себя что-то полезное рассказывает. В команде всегда есть разработчики, у которых больше опыта. Неплохо было бы организовать день мастер-классов, составить график, где каждый разработчик должен выступить в течение 10-20-ти минут, рассказать о чем-то новом, показать технологию, сделать минимальную презентацию и просто поделиться знаниями, которые он получил на последнем проекте или вычитал, например, в статье. Польза в этом всем в том, что все понимают, над чем они работают, с какими сталкиваются задачами и технологиями, поэтому такие мастер-классы могут быть максимально эффективными для команды.
Если компания пишет, например, используя Angular, то все мастер-классы нужно заточить под Angular и культивировать освоение тех частей этой библиотеки, которые необходимы для работы в проекте. Тимлидер может составить список докладов, и каждый сможет их проводить, будет общая копилка тех тем, по которым разработчик может провести мастер-класс и сделать расписание – это будет наиболее эффективный способ поделиться знаниями в команде.
Также как способ - экстремальное программирование, вместе работать с одной задачей. Кто-то один знает процесс и диктует, а второй набирает код. Экстремальное программирование никто не отменял, но не в каждом проекте оно может примениться, чтобы более опытный специалист смог передать свои знания.
Як реалізувати інтернаціоналізацію в React
Автор: Yury Dymov
Об авторе
Юрий Думов работает архитектором программного обеспечения в SAP, имеет более 10 лет опыта в разработке веб и мобильных приложений.
Прежде всего, давайте введем некоторые сокращения. Internationalization - достаточно длинное слово, поэтому предлагаю его заменить в нашем контексте на “intl”.
Интернационализация в общем плане может быть разделена на следующие подпункты:
Определение пользовательской локали
Перевод UI-элементов, заголовков, подсказок и прочего
Поддержка местных специфических сервисов, таких как даты, валюты и числа
На заметку: в этой статье я заострю ваше внимание лишь на front-end части. Мы разработаем несложное универсальное React-приложение с полной поддержкой интернационализации.
Для начала предлагаю воспользоваться моим репозиторием. Здесь у нас есть веб-сервер Express для серверного рендеринга, вебпак для построения клиентского JS, Babel для конвертации современного JavaScript в ES5. Также мы будем использовать npm-run, nodemon для запуска веб-сервера под средой разработчика и webpak-dev-server для ассетов.
Нашей точкой входа в серверное приложение будет служить server.js. Здесь мы загружаем Babel и babel-polyfill для создания прочего серверного кода в современном стандарте JavaScript. В качестве бизнес-логики сервера мы используем src/server.jsx. Тут мы устанавливаем Express-сервер для прослушки порта 3001. Для рендеринга мы используем очень простой компонент components/App.jsx, который также является частью точки входа в универсальное приложение.
Точкой входа в клиентский JS нам служит src/client.jsx. Тут мы фиксируем корневой компонент - component/App.jsx - для placeholder'а react-view в HTML-разметке, предоставляемой Express-сервером.
Таким образом, сейчас мы склонируем репозиторий, запустим npm-install и выполним nodemon и webpack-dev-server одновременно в двух консолях.
В первой консоли:
И во второй:
Наш веб-сервер должен быть доступен по localhost:3001. Откройте предпочитаемый вами браузер и убедитесь в этом сами!
Итак, мы готовы начать.
Определение пользовательской локали
Существует два возможных решения этого вопроса. По какой-то причине большинство популярных веб-сайтов, включая Skype и NBA, используют гео-IP для определения местоположения пользователя, таким образом определяя его родной язык. Подобный подход не только является дорогим в плане реализации, но и еще не совсем точным. Сейчас очень много людей путешествует, по этой причине местоположение пользователя не является надежным ориентиром при выборе подходящего языка приложения. Вместо этого мы предпочтем второй способ решить данную проблему при помощи обработки на стороне сервера заголовка Accept-Language. Этот заголовок отправляется любым более-менее современным браузером.
-Language
Этот заголовок предоставляет информацию о возможных вариантах языка, принятого в качестве ответа. Каждый язык обладает своим «приоритетом», показывая, как часто пользователь может его использовать. По умолчанию уровень «приоритетности» равен 1. К примеру, «Accept-Language: da, en-gb;q=0.8, en;q=0.7» означает «я предпочитаю датский, но могу также принять британский или другие виды английского».
(Также стоит упомянуть, что сей подход так же несовершенен. К примеру, пользователь может посетить ваш веб-сайт из интернет-кафе или публичного ПК. Лучше всего разработать виджет, при помощи которого пользователь на интуитивном уровне сможет поменять язык сайта.)
Реализация определения локали пользователя
Вот пример кода веб-сервера Node.js. Мы используем пакет accept-language, что извлекает локали из http-заголовков и находит наиболее предпочтительные, исходя из поддерживаемых вашим веб-сайтом. Если таковые не были найдены, тогда сайт будет использовать свою дефолтную локаль.
Приступим к установке пакетов:
После чего в src/server.jsx у нас будет следующее:
Здесь мы импортируем accept-language и устанавливаем поддержку английских и русских локалей. Также мы реализовываем функцию detectLocale, что извлекает значение локали из куки. Если ни одна не была обнаружена, начинается обработка Accept-Language. Наконец, мы выбираем дефолтную локаль. После обработки запроса мы добавим заголовок Set-Cookie для обнаруженной локали в ответ. Это значение будет использовано для всех последующих запросов.
Перевод UI-элементов, заголовков, подсказок и прочего
Здесь я собираюсь использовать React Intl-пакет. Это наиболее популярная и, так сказать, проверенная боем реализация интернационализации для React-приложений. Впрочем все библиотеки так или иначе строятся по одному принципу: они обеспечивают нас компонентами высшего порядка, что внедряют уже готовые функции интернационализации для обработки сообщений, дат, номеров, валют посредством специальных фич React.
Во-первых, мы должны установить провайдер интернационализации. Для этого мы немного изменим src/server.jsx и src/client.jsx.
src/server.jsx:
здесь src/client.jsx:
Так, теперь IntlProvider-дочерний компонент получит доступ к функциям интернационализации. Давайте добавим переведенный текст в наше приложение и клавишу для изменения локали. У нас есть два способа, как это можно сделать: через FormattedMessage или через formatMessage – функцию. Разница в том, что компонент будет обернут в span-тэг, что хорошо для текстовых данных, но не хорошо для значений HTML-атрибутов, таких как alt и title. Давайте опробуем и их!
Вот src/components/App.jsx:
Отметьте, что атрибут id должен быть всегда уникальным для всего приложения в целом, так что было бы не лишним установить для себя некоторые правила именования сообщений. Я предпочитаю следовать формату «имяКомпонента.некийУникальныйИдентификатор». В качестве некой дефолтной локали будет использовано сообщение defaultMessage. Атрибут description предоставит некую информацию для переводчика.
Перезапустите nodemon и обновите страницу в браузере. Вы должны увидеть «Hello World». Но если вы открываете статью при помощи инструментов разработчика, вы увидите, что текст теперь внутри тэга span. В этом случае это не ошибка, но иногда мы предпочитаем просто получить текст, без никаких дополнительных тэгов. Для этого нам нужен прямой доступ к объекту интернационализации React Intl.
Давайте вернемся назад к src/components/App.jsx:
Нам нужно написать гораздо больше кода, чем раньше. Во-первых, мы используем injectIntl, который «упаковывает» наш компонент приложения и внедряет intl-объект. Чтобы получить переведенное сообщение, нам нужно вызвать formatMessage и передать в качестве параметра message. Этот message должен иметь свой уникальный идентификатор и атрибуты defineMesasges из React Intl.
Лучшее, что есть в React Intl, так это его экосистема. Давайте добавим babel-plugin-react-intl к нашему приложению и построим словарь трансляции. Мы передадим этот словарь переводчикам, которым не нужно никаких задатков программирования для выполнения своей работы.
.babelrc:
Перезапустите nodemon, и вы увидите, что папка build/messages была успешно создана в корневой директории проекта, вместе с некоторыми другими папками и файлами внутри. Теперь нам необходимо собрать эти файлы в один JSON. Для этого вы можете использовать мой скрипт. Сохраните его как scripts/translate.js.
Теперь нам нужно добавить новый скрипт в package.json:
Что же, попробуем!
В конце вы должны увидеть файл en.json в build/lang.
И все работает! Теперь пришло время для кое-чего поинтересней. На стороне сервера мы можем загрузить все переводы в память и, соответственно, выдавать их в зависимости от характера запроса. Однако на клиентской стороне этот подход неприемлем. Потому вместо этого мы будем один раз принимать json-файл со всеми переводами, а клиент автоматически определит, какой из текстов ему нужен.
Скопируем результирующий файл в public/assets.
На заметку: если вы пользуетесь Windows, симлинки для вас недоступны. Таким образом, вам нужно будет вручную копировать команды каждый раз, как только вы будете перестраивать ваши переводы.
public/assets/ru.json применим следующее:
Теперь нам нужно повязать серверный и клиентский коды.
Для сервера наш src/server.jsx должен выглядеть так:
Здесь мы делаем следующее:
Кэшируем сообщения и специфичный для данной локали JS для валют, DateTime, Number во время запуска приложения.
Расширяем метод renderHTML так, что мы можем вставить специфичный для данной локали JS прямо в разметку.
Предоставляем переведенные сообщения IntlProvider (все те сообщения теперь доступны в качестве дочерних компонентов).
Что же касается стороны сервера, во-первых, нам нужно установить библиотеку для выполнения AJAX-запросов. Я предпочитаю использовать изоморфное обновление, так как, скорее всего, нам предстоит запрашивать данные из сторонних API, и изоморфное обновление очень хорошо с этим справляется.
Вот src/client.jsx:
Также мы должны затронуть src/server.jsx, чтобы Express предоставлял json с переводом на сторону клиента. Заметьте, что на продакшине вы, скорее всего, будете использовать что-то вроде nginx.
После инициализации JavaScript, client.jsx возьмет локаль из куки и запросит JSON с переводом. Во всем остальном наше приложение будет работать, как и раньше.
Пришло время проверить, как все будет работать в браузере. Откройте вкладку «Network» в панели разработчика и удостоверьтесь, что JSON с переводом был успешно получен нашим клиентом.
Подведя итог, давайте добавим небольшой виджет для изменения локали в src/components/LocaleButton.jsx:
И так же в src/components/App.jsx:
Заметьте, как только пользователь меняет свою локаль, мы перезагружаем страницу, чтобы убедиться, что новый JSON-файл с переводом был успешно извлечен.
Теперь же время протестировать! Окей, мы изучили, как определять локаль пользователя и как отображать переведенные сообщения. Перед тем, как двигаться в направлении заключительной части, давайте обсудим пару также немаловажных нюансов.
Плюрализация и шаблоны
В английском большинство слов могут принимать одну или две возможные формы: «одно яблоко», «много яблок». В других языках все намного сложнее. К примеру, русский имеет 4 различные формы. Надеемся, React сумеет справиться и с этим. Он также поддерживает шаблоны, так что вы можете предоставить переменные, которые могут быть подставлены в шаблон во время рендеринга. Вот как это работает.
В src/components/App.jsx у нас есть:
Тут мы определяем шаблон с переменной count. Мы напечатаем или «одно яблоко», если значение переменной равно 1, 21 и так далее, или «два яблока» в противном случае. Нам нужно передать все переменные в formatMessage.
Давайте перестроим наш файл переводов и добавим русский перевод для теста.
Вот наш public/assets/ru.json файл:
Теперь все случаи предусмотрены!
Поддержка местных специфических сервисов, таких как даты, валюты и числа
Ваша информация будет представляться по-разному в зависимости от локали. К примеру, русская локаль нам покажет $500.00 и 12/10/2016.
Intl предоставляет React-компоненты для такого типа данных, которые автоматически обновляются каждые 10 секунд, если вы за это время не перезаписывали значения.
это в src/components/App.jsx:
Обновите браузер и проверьте страницу. Вам необходимо будет подождать 10 секунд, чтобы увидеть, как обновится FormattedRelative.
Круто, не правда ли? Что же, теперь мы можем столкнуться еще с одной проблемой – универсального рендеринга.
В среднем между формированием разметки и инициализацией JS проходит порядка 2-х секунд. Это значит, что все DateTime`сы, сгенерированные на странице, могут иметь разные значения на стороне клиента и сервера. Что, как следствие, разрушает универсальный рендеринг.
Вот src/server.jsx:
вот src/client.jsx:
Перезапустите nodemon и проблема почти исчезнет! Она может, правда, остаться в случае, если вы используете Date.now() вместо показаний, записанных в базе. Чтобы сделать пример более «жизненным», заменим в app.jsx Date.now() на последний таймштамп, что-то вроде 1480187019228.
(Впрочем, вы можете столкнутся с другой проблемой – когда сервер не в состоянии отрендерить DateTime в нормальном формате. Это потому, что 4 версия Node.js по умолчанию не поддерживала Intl.)
Звучит слишком хорошо, чтобы быть правдой, не так ли? Мы как истинные фронт-енд разработчики всегда были на стороже того, что касается браузеров и платформ. React Intl использует нативный браузерный API для обработки форматов DateTime и Number. И, несмотря на тот факт, что подобная функциональность была представлена в 2012 году, до сих пор есть современные браузеры, которые ее все еще не поддерживают. Даже Safari поддерживает ее только частично. Вот таблица с детальной информацией:
Это значит, что если вы желаете покрыть большинство браузеров, которые не поддерживают Intl API на нативном уровне, polyfill для вас просто незаменим. Хвала Всевышнему, существует Intl.js. С одной стороны, кажется, вот оно – идеальное решение, но, как показывает мой опыт, всегда существуют свои недостатки. Во-первых, вам нужно добавить Js-bundle, что несколько ресурсоемко. Также для уменьшения размера вам нужно будет передавать ваш Intl.Js только для браузеров, у которых нет своей нативной поддержки. Конечно, все эти техники уже давным-давно известны, и существует великое множество статей, посвященных им. Но все равно, Intl.js – не абсолютное решение, так как все же представления DateTime и Number на стороне сервера и на стороне клиента могут несколько отличаться, что, разумеется, влечет за собой ошибки при серверном рендеринге.
Наконец, я пришел к своему собственному решению, которое хоть и имеет свои недостатки, но мои запросы в большинстве случаев оно устраивает. Я реализовал очень поверхностный polyfill, что имеет лишь небольшую часть из требуемой функциональности. В то время, как в большинстве случаев подобное решение непригодное, оно лишь добавляет лишние 2 КБ к размеру JS-файла, так что даже нет необходимости реализовывать динамическую загрузку кода для устаревших браузеров, что значительно упрощает решение в целом.
И в заключение
Возможно, сейчас вас не покидает чувство, как будто здесь написано слишком сложное решение. Также, возможно, сейчас вы подумываете о том, чтобы реализовать все самим. Я бы не советовал этого делать. В конце концов, вы все равно придете к выводам, представленным в данной статье. Или, что хуже, зайдете в тупик одного решения и не сможете увидеть остальные. Вы можете подумать, что можно легко решить проблему с Intl API, используя вместо него Moment.js (я специально не рассматривал другие библиотеки, так как они либо неподдерживаемые, либо неиспользуемые). К счастью, я уже опробовал это, так что я могу сохранить вам много времени. Moment.js монолитен и очень тяжел, так что если для кого-то он и подойдет, то остальная масса пользователей будет неудовлетворенной результатом. Разработка собственного polyfill не звучит интригующе, так как вам наверняка придется выделить определенное время для борьбы с возникающими при этом багами. Подведя итог, могу лишь сказать, что не существует идеального решения касательно проблемы на данный момент: просто выберите то, что вам подойдет лучше всего.
Надеюсь, эта статья дала вам все, что нужно знать для создания интернационализируемого React front-end приложения. Теперь вы выучили, как определять локаль пользователя, сохранять ее в куки, писать виджет для изменения локали и многое другое! Также вы ознакомились с некоторыми возможными проблема и ловушками, в которые вы можете попасть в процессе написания приложения.
Удачи в разработке!
Автор перевода: Евгений Лукашук
Источник
Перехід з jQuery на Vue.js
Автор: Sarah Drasner
Об авторе
Сара Дрезнер - заслуженный спикер и senior разработчик в Microsoft, автор статьей о трюках и хитростях CSS.
Нельзя просто так упустить все интриги, возросшие вокруг существующий JavaScript - фреймворков, но также не стоит забывать, что они явно не являются универсальными и каждый тип проекта требует что-то "свое". Возможно, вы не захотите устанавливать большое количество различных дополнений, чтобы просто реализовать небольшую абстракцию. Возможно, адаптация проекта под новые системы сборки, различные методы деплоя будет означать большое количество времени и усилий, которые вы будете не в состоянии включить в прайс клиенту. Возможно, вы не хотите писать в HTML JavaScript. Список может расти до бесконечности.
Что многие люди могут не знать, так это то, что вы можете легко внедрить Vue.js в ваш проект точно так же, как вы внедряете jQuery. Не нужно ничего перестраивать. Vue достаточно гибкий - в том плане, что вы можете его использовать прямо в HTML.
Итак, представим, что ваш код имеет следующий вид:
Вы можете в буквальном смысле изменить скрипт-тег и продолжить использовать HTML & JS точно так же, как вы использовали его до этого. Вам не нужно ничего переписывать. Вам не нужно интегрировать веб-паки. И вам определенно не нужно устанавливать никаких криповых чудовищ.
Вы можете заменить тэги и оставить разметку "как есть". Что радует, так это несказанная простота, гибкость и адаптируемость Vue.js, что вы можете увидеть на протяжении чтения данной статьи. Что же касательно размера, тут нас тоже ждет приятная особенность: всего лишь 86 КБ для версии 2.5.3 и 87 для более новой версии 3.2.1.
Давайте рассмотрим некоторые наиболее распространенные примеры использования нового фреймворка и убедимся в его неоспоримых преимуществах.
Перехват пользовательского ввода
Наиболее распространенным примером использования JavaScript является отлавливание введенной пользователем в веб-формы информации. В нашем примере для упрощения мы не будем рассматривать комплексные формы, но для понимания этого будет целиком достаточно.
Чтобы отловить информацию, вводимую пользователем, мы можем сделать следующее:
See the Pen 1 by Jeka Muzyka (@jeka-muzyka) on CodePen.
See the Pen 2 by Jeka Muzyka (@jeka-muzyka) on CodePen.
Я использую этот пример, потому что он наглядно демонстрирует некоторые сильные стороны Vue.js. Он реализует особенности react, что делает его очень чуствительным в плане изменений. Демонстрацию вы можете увидеть, когда попытаетесь ввести что-то. Как можно заметить, вся информация обновляется практически мгновенно.
Вы также можете заметить это и в версии с JQuery - контролируя элементы DOM-дерева и работая с событиями, вызываемыми при изменении содержания его элементов.
В версии Vue.js мы сохраняем состояние элемента. Если более детально, то мы привязываем к нашему конечному скрипту DOM-элемент напрямую. Особенность в том, что даже в случае изменения структуры DOM-дерева и HTML в целом, конкретный DOM-элемент будет надежно привязан к нашему Vue.js - событию. Де-факто, на вводе мы используем атрибут v-model, тем самым обозначая хранение информации этого поля в JavaScript.
Однако это далеко не единственный способ хранения состояния. Потому двигаемся дальше.
Хранение введенных данных в рамках индивидуального события
Особенность работы Vue.js заключается в том, что нам не нужно думать об особенностях реализации конкретного DOM-события. По сути, мы уже знаем, что мы желаем "перехватить". Мы просто указываем событию, на который из элементов срабатывать. Тогда как с использованием JQuery мы жестко привязываемся к структуре DOM и прочим DOM-событиям. Увидеть разницу мы сможем в следующем примере:
See the Pen new by Jeka Muzyka (@jeka-muzyka) on CodePen.
See the Pen 4 by Jeka Muzyka (@jeka-muzyka) on CodePen.
В этой версии JQuery был упрощен, так как нам не нужно было отлавливать события при каждом нажатии клавиши, но в то же время все остальные условия соблюдены. Наш код в jQuery также будет подобен этому:
"Отловите элемент, просмотрите, что он делает, перехватывайте изменения, обрабатывайте полученные данные."
Сравним: во Vue мы контролируем все изменения DOM-дерева. Мы привязываемся к конкретным элементам. По сути, мы имеем небольшую абстракцию под названием v-model.lazy. Vue тепер знает, что сохранять состояние данных до того, как были произведены первые изменения, нельзя. Отлично!
Классы
Следующая вещь, которую мы сейчас рассмотрим, является привязкой CSS-классов, так как наш всеми любимый и обожаемый Гугл сообщает, что это также наиболее популярный случай использования jQuery.
See the Pen 5 by Jeka Muzyka (@jeka-muzyka) on CodePen.
See the Pen 6 by Jeka Muzyka (@jeka-muzyka) on CodePen.
Опять же, что мы здесь можем видеть, так это то, что в версии с jQuery мы храним состояние объекта в DOM-дереве. Элемент имеет свой класс, jQuery принимает решение на базе существующего класса, проверяющего привязку к DOM. В версии с Vue мы храним условие и применяем к нему стили в зависимости от состояния этого условия. Мы не обращаемся к DOM за этой информацией, мы храним ее сами.
Мы храним active в данных, кнопка изменяет состояние условия и, в зависимости от условия, применяется к примеру .red. Даже состояния доступа, aria-pressed, сохраняются гораздо быстрее, так как у нас нет необходимости хранить все в vue-скрипте. Мы можем изменять состояние напрямую при помощи слова active.
Если вы думали, что использование Vue породит большее количество кода, последние несколько примеров должны были заставить вас убедиться в обратном.
Скрытие и отображение
Другой общий случай использования jQuery является отображением и сокрытием элементов. jQuery всегда хорошо справлялся с этой задачей, потому давайте посмотрим, как все будет выглядеть со стороны Vue.
See the Pen 7 by Jeka Muzyka (@jeka-muzyka) on CodePen.
See the Pen 8 by Jeka Muzyka (@jeka-muzyka) on CodePen.
Оба фреймворка успешно справляются с поставленной задачей, но все же и здесь есть свои причины, почему я отдаю предпочтение Vue.js. Vue обладает инструментом под названием Vue devtolls. Это не то же самое, что Chrome devtools, но когда я их использую, я получаю больше специфической информации, связанной непосредственно с Vue.js
И в jQuery и в Vue элементы успешно скрываются и появляются вновь. Но что, если что-то пойдет не так? Что, если что-то в нашем коде работает не так, как это было задумано? В случае с jQuery для отладки мы бы скорее всего использовали console.log и были бы таковы.
Это все, конечно, хорошо, но в случае с Vue он сам нам предоставит всю необходимую информацию о нем самом. На пикче ниже мы можем увидеть, как элемент скрывается\появляется и как изменяется его состояние в специальном окне. Если DOM по какой-то причине не будет работать так, как мы от него ожидаем, вся необходимая информация будет легко отображена во Vue.
Что еще мне нравится, так это то, что v-if очень удобно принять в других случаях. Я могу использовать v-show, если вещь будет скрыватся и отображатся часто: v-if полностью "демонтирует" элемент, тогда как v-show просто изменит видимость. Это достаточно важно, так как позволяет улучшить производительность. Я легко могу установить целые каскады условий, в то время как повторить подобное с jQuery - слегка затруднительно.
See the Pen 9 by Jeka Muzyka (@jeka-muzyka) on CodePen.
See the Pen 10 by Jeka Muzyka (@jeka-muzyka) on CodePen.
В этом примере значения с приставкой Vue реагируют на код достаточно натурально и с меньшим объемом кода. Однажды попробовав этот стиль, логику приложений, разработанных под Vue, использовать будет значительно проще.
Передача формы
Так уж исторически сложилось, что отправка формы посредством Ajax является наиболее "каноничным" примером использования jQuery. А потому мы просто обязаны рассмотреть альтернативу. На самом деле, Vue не обладает встроенными вещами навроде Ajax. Обычно вместо этого здесь используется Axious (js-библиотека для генерации http-запросов).
Этот пример будет несколько более сложным, чем предыдущие. Мы собираемся произвести следующее:
До начала ввода в форму клавиша будет серой. После чего она примет "активный" класс и станет голубой.
Когда мы отправляем форму, страница не будет перезагружаться.
Как только форма принята, мы отобразим ответ на странице.
See the Pen 11 by Jeka Muzyka (@jeka-muzyka) on CodePen.
Здесь за управление классом клавиши отвечают строки 2-10. Похоже на то, что мы делали ранее. Мы передаем в параметр под названием событие форму и говорим event.preventDefault(), дабы запретить перезагрузку страницы. После чего мы собираем всю информацию с формы и отправляем через Ajax запрос (.done()).
See the Pen 12 by Jeka Muzyka (@jeka-muzyka) on CodePen.
В версии Vue мы биндим поля через v-model. Мы проверяем имена для связки с классом. Вместо передачи информации и загрузки страницы event.preventDefault(), нам всего лишь нужно написать @submit.prevent в нашем элементе формы. Для передачи запроса же мы используем Axious.
Конечно, так же можно произвести и валидацию, отлавливание ошибок, тесты и так далее. Но для понимания логики работы с Vue, как мне кажется, достаточно и этих небольших примеров.
И в заключение
Нет ничего плохого в том, чтобы продолжать использовать jQuery. Цель этой статьи - всего лишь показать, что Vue так же хорош в качестве некой такой абстракции для небольших сайтов. Этот фреймворк оптимален в размерах, прост в работе и освоении, достаточно тривиален и прекрасно интегрируется в HTML & JS без необходимости перестраивать приложение.
Благодаря гибкости Vue передача кода на стадию билда и общая компонентная структура не являются чем-то сложным. На самом деле - это очень даже весело. Попробуйте сами! Вы можете скаффолдить весь Vue на уровне продакшена просто при помощи пары терминальных команд. Подобным образом вы можете работать с отдельными компонентами, не трогая HTML & JS. Вам не нужно менять конфигурацию вашего веб-пака, разве что вы не захотите сделать что-то специфическое.
Vue хорош во всем, что касается адаптивности, так как вам не нужно ничего менять в вашей разметке, чтобы работать с новым, качественными фреймворком.
Удачи в разработке!
Автор перевода: Евгений Лукашук
Источник
Як правильно працювати з REST API
Автор: Zell Liew
Коротко про мене
Мене звати Зел, я розробник-фрілансер із Сінгапуру. У вільний від роботи час я люблю розбиратися в коді і принагідно публікувати у своєму блозі ті цікавості, які я виявив чи вивчив.
Вступ
Швидше за все вам уже доводилося чути про такий термін, як REST API, особливо якщо ви стикалися з необхідністю отримання даних з іншого джерела (такого як Twitter або GitHub). Але що ж все-таки це таке? Що ми можемо робити з цим і як ми можемо це використовувати?
У цій статті ви дізнаєтеся все про REST API для того, щоб працювати з ними та читати пов'язану з ними документацію.
Що ж таке REST API?
Давайте уявимо, що ви намагаєтеся знайти фільми про Бетмена на YouTube. Ви відкриваєте сайт, вбиваєте у форму пошуку слово «Бетмен», тиснете «Окей» і бачите список фільмів про супергероя. Так само працює і WEB API. Ви шукаєте щось і отримуєте список результатів від ресурсу, до якого здійснюєте запит.
Дослівно API розшифровується як Application Programming Interface. Це набір правил, що дозволяє програмам спілкуватися одна з одною. Розробник створює API на сервері та дозволяє клієнтам звертатися до нього.
REST – це архітектурний підхід, що визначає, як API мають виглядати. Читається як "Representational State Transfer". Цьому набору правил і слідує розробник під час створення свого застосунку. Одне з цих правил каже, що при зверненні до певної адреси ви повинні отримувати певний набір даних (ресурс).
Кожна адреса - маршрут, пакет даних - запит, у той час як результуючий ресурс – відповідь.
Анатомія запиту
Важливо розуміти структуру запиту:
Маршрут відправки.
Тип методу.
Заголовки.
Тіло (або дані).
Маршрут – це адреса, за якою надсилається ваш запит. Його структура приблизно така:
Root-endpoint - це точка прийому запиту на стороні сервера (API). Наприклад, кінцева точка GitHub - https://api.github.com.
Шлях визначає ресурс, до якого здійснюється запит. Це щось на кшталт автовідповідача, який просить вас натиснути 1 для одного сервісу, 2 для іншого і так далі.
Для розуміння того, які саме шляхи вам доступні, вам слід переглянути документацію. Наприклад, припустимо, ви хочете отримати список репозиторіїв для конкретного користувача на Git. Згідно з документацією, ви можете використати наступний шлях для цього:
Вам слід підставити під пропуск ім'я користувача. Наприклад, щоб знайти список моїх репозиторіїв, ви можете використати маршрут:
Остання частина маршруту – це параметри запиту. Технічно запити не є частиною REST-архітектури, але на практиці зараз все ґрунтується на них. Тож давайте поговоримо про них детальніше. Параметри запиту дозволяють використовувати у запиті набори пар «ключ-значення». Вони завжди починаються знаком питання. Кожна пара параметрів після чого розділяється амперсандом (щось подібне до цього):
Як тільки ви намагаєтеся отримати список репозиторіїв для користувача, ви додаєте ці три опціональні параметри і після чого отримуєте наступний результат:
Якщо ж ви бажаєте отримати список моїх недавно запушених репозиторіїв, вам слід ввести наступне:
Отже, як же зрозуміти, що маршрути робочі? Що ж, настав час перевірити їх на практиці!
Тестування за допомогою Curl
Ви можете надіслати запит за допомогою будь-якої мови програмування. JavaScript може використовувати методи на кшталт Fetch API або JQuery`s Ajax Method. Рубі використовує інше. І так далі.
У цій статті я використовуватиму таку утилітку, як Curl. Справа в тому, що вона вказана в офіційній документації для веб-сервісів. Якщо ви зрозумієте, як використовувати цю утиліту, ви зрозумієте, як працювати з API. Після чого ви можете робити запити будь-якою зручною для вас мовою.
Перед тим, як продовжити, слід переконатися, що Curl встановлений на вашій машині.
Якщо ж він не встановлений, саме час встановити. У такому разі ви отримаєте помилку "command not found".
Для того щоб використовувати утиліту, необхідно ввести наступне (за прикладом):
І як тільки ви підтверджуєте введення, ви отримуєте відповідь (на зразок цього):
Щоб отримати список користувацьких репозиторіїв, вам слід змінити запит за тим же принципом, який був обговорений раніше. Наприклад, щоб отримати список моїх репозиторіїв, вам слід ввести наступне:
Якщо ж ви бажаєте включити параметри запитів, переконайтеся, що ви їх екрануєте. Справа в тому, що без екранування знаки питання і рівності розцінюються системою як спецсимволи і виконання команди відбудеться з помилкою.
Також спробуйте інші команди та зробіть запити! В результаті ви отримуєте схожі відповіді.
JSON
JSON – JavaScript Object Notation – загальний формат для надсилання та прийому даних за допомогою REST API. Відповідь, що відправляється Github, також міститься у форматі JSON.
Зміст об'єкту цього формату приблизно наступний:
Повертаємось до анатомії запиту.
Ви вивчили, що запит складається із чотирьох частин:
Маршрут відправки.
Тип методу.
Заголовки.
Тіло (або дані).
Тепер давайте спробуємо розібратися з рештою.
Тип методу
Метод позначає тип запиту, який здійснюється; де-факто він є специфікацією операції, яку повинен здійснити сервер. Усього існує п'ять типів запитів:
GET
POST
PUT
PATCH
DELETE
GET – використовується для отримання з боку серверу певного ресурсу. Якщо ви здійснюєте цей запит, сервер шукає інформацію та відправляє її вам назад. По суті, він здійснює операцію читання на сервері. Дефолтний тип запитів.
POST – необхідний для створення певного ресурсу на сервері. Сервер створює в базі даних нову сутність та сповіщує вас, чи був процес створення успішним. По суті, це операція створення.
PUT та PATCH – використовуються для оновлення певної інформації на сервері. У такому разі сервер просто змінює інформацію існуючих сутностей у базі даних та повідомляє про успіх виконання операції.
DELETE – як і випливає з назви, видаляє вказану сутність із бази чи сигналізує про помилку, якщо такої сутності в базі не було.
Сам же API дозволяє вказати, який метод має бути використаний у певних контекстних ситуаціях.
GET запит у цьому випадку необхідний, щоб одержати список всіх репозиторіїв зазначеного користувача. Також можна використовувати curl:
Спробуйте надіслати цей запит. Як відповідь ви отримаєте вимогу про аутентифікацію.
Заголовки
Заголовки використовуються для надання інформації як клієнту, так і серверу. Взагалі, їх можна використовувати для багато чого; наприклад, та сама автентифікація та авторизація. На офіційній сторінці MDN можна знайти список доступних заголовків.
Заголовки являють собою пари ключів-значень. Приклад:
Також приклад із використанням curl:
(Примітка: заголовок Content-Type у випадку Github для роботи не є обов'язковим. Це всього лише приклад використання заголовка в запиті, нічого більше).
Для перегляду надісланих заголовком даних можна використовувати наступне:
Тут зірочка відноситься до додаткової інформації, наданої за допомогою curl. > відноситься до заголовків запиту, а <, відповідно, - до заголовків відповіді.
Щоб надіслати інформацію з curl, використовуйте наступне:
Для відправки множинних полів ми можемо використати декілька подібних конструкцій:
Також, якщо необхідно, ви можете розбити ваш запит на декілька ліній для забезпечення більшої читабельності:
Якщо ви знаєте, як розгорнути сервер, ви можете створити власний API та протестувати свої запити. Якщо ж ні, обов'язково спробуйте. Існує безліч інформації, присвяченої цьому.
Якщо ж бажання розгортати свій сервер немає, спробуйте безкоштовну опцію Request bin.
Після чого ви отримаєте адресу, яку спокійно зможете тестувати.
Переконайтеся, що ви створюєте власний request bin, якщо ви хочете протестувати саме ваш запит. Зважайте на те, що дефолтний час існування request bin – 48 годин. Тому ті приклади адрес, які я тут наводжу, на момент прочитання статті давно застаріли.
Тепер спробуйте надіслати деяку інформацію, після чого оновіть свою сторінку.
Якщо все пройде успішно, ви побачите наступне:
За замовчуванням curl відправляє дані так, ніби вони були відправлені за допомогою полів форм. Якщо ви бажаєте надіслати дані через JSON, ваш Content-Type повинен дорівнювати application\json, внаслідок чого вам необхідно відформатувати дані у вигляді JSON-об'єкту.
По суті, це все, що вам необхідно знати про структуру запиту.
Тепер давайте згадаємо про аутентифікацію. Що ж це таке і навіщо вона потрібна?
Аутентифікація
Ви б не дозволили нікому чужому отримати доступ до вашого банківського рахунку без спеціального дозволу, чи не так? За таким же принципом розробники не дозволяють неавторизованим користувачам робити на сервері все, що їм заманеться.
Оскільки POST, PUT, PATCH, DELETE запити змінюють базу даних, розробники повинні завжди бути на варті неавторизованого доступу до них. Проте іноді GET запити також вимагають аутентифікації (наприклад, коли ви хочете переглянути стан вашого банківського рахунку).
У випадку з вебом існує два способи представитися системі:
Через нік і пароль (базова автентифікація)
Через секретний токен
Секретний токен дозволяє представити вас системі через соцмережі на кшталт Github, Google, Twitter і так далі.
Тут же я розгляну лише базову автентифікацію.
Для виконання базової аутентифікації ви можете використовувати наступне:
Спробуйте залогінитися під свій профіль за запитом, вказаним вище. Як тільки ви успішно увійдете у свій профіль, ви побачите відповідь "problems parsing JSON".
Чому? Все просто: системі ви представилися, але - от біда - нічого корисного їй не надали. Усі типи запитів потребують певної інформації.
Тепер же давайте поговоримо про статус-коди та можливі помилки.
Статус-коди та можливі помилки
Деякі з повідомлень, наведених вище, якраз і належать до кодів помилок. Логічно, що вони з'являються лише тоді, коли щось іде не зовсім так, як було заплановано. Що ж до статусу кодів, вони дозволяють вам пізнати успіх (або невдачу) під час виконання певного запиту. Бувають статус-коди від 100 до 500+. Загалом їх можна поділити на такі групи:
200+: запит успішний
300+: запит перенаправлений на інший маршрут
400+: помилка на стороні клієнта
500+: помилка на стороні сервера
Ви можете відлагодити статус відповіді за допомогою –v або –verbose. Наприклад, я спробував отримати доступ до певного ресурсу без авторизації. Відповідно, я спіймав помилку:
У випадку ж, коли запит невірний через помилку в самій інформації, що передається, ви отримуєте статус-код 400:
Версії API
Час від часу розробники оновлюють свої API. Іноді оновлення можуть бути такими сильними, що розробник бажає здійснити реліз нової версії. У такому випадку, якщо ваш застосунок ламається, це відбувається через те, що ви писали код з урахуванням старого компонента, тоді як новий дещо відрізняється в плані реалізації.
Запросити поточну версію API можна двома шляхами.
Через маршурт
Через заголовок
Наприклад Твіттер використовує перший спосіб. На момент написання версія Twitter API була 1.1.
Водночас GitHub використовує інший спосіб:
На закінчення
У цій статті ми розглянули, що таке REST API і як його можна використовувати спільно з curl. Крім того, ви також вивчили, як залогінитись за допомогою запиту і що таке статус-код.
Я щиро сподіваюся, що ця стаття дозволила вам підвищити свій рівень загальних і не дуже знань щодо такого важливого аспекту веб-розробки. Буду радий будь-яким вашим коментарям тут.
Автор перекладу: Євген Лукашук
Джерело
Ще більше матеріалів на цю тему:
ASP.NET Core Web API. Практичний курс
ASP.NET WEB API 2
REST API в Node.js
JAX-RS Client API. Asynchronous REST
Створення API на PHP та JavaScirpt
Найкращі книги з програмування
Автор: Редакция ITVDN
В свое время я работал и продолжаю работать сейчас разработчиком. Начал в качестве веб-программиста в 2004 году, перешел на полный стек в 2009 году, начал разработку для iOS в 2013.
Я начал свой путь программиста с прочтения трех книг: одна была про HTML, другая – про CSS и третья, соответственно, об SQL. Прочие знания я получил из Google, Stack Overflow и блогов. Вообще, Интернет – прекрасная штука. Каждый день я прочитывал по 5 или больше тематических статьей. И, что самое главное, все эти знания были бесплатны.
В основном мои знания о программировании были получены из университета и опыта работы. Как-то так. Действительно, получается, что большая часть из того, что вы изучаете о программировании, были получено в основном во время решения определенных практических задач.
То, что меня также интересует – это чтение различных специализированных книг. Увы, но размеры списков по типу «Обязательных к прочтению для разработчиков» выходят далеко за рамки адекватных. Ситуация со сжатым списком из этого списка также ненамного лучшая…
Каждая из книг хороша по-своему, но и целой жизни будет мало, чтобы прочитать все это. Лично меня это всегда несколько сбивало с толку, так как выбрать первую книгу для изучения становится весьма проблематично.
Потому я и решил немного покопаться в списках и создать один «универсальный» список, в котором будут включены книги, общие для всех рассмотренных списков.
Конечно, прочтение всех этих книг не сделает из вас профессионального программиста, но использование того, что было выучено из книг на практике – сделает. Лично я для себя решил выработать привычку прочитывать по крайней мере одну книгу в два месяца.
Полный список содержит 139 книг. Все книги, которые вы увидите в этом списке, находятся на вершине популярности рассмотренных списков.
В этом списке вы не найдете книгу о том, как стать Java-разработчиком, но вы можете увидеть книги, которые используют язык Java для приведения практических примеров, рассматриваемых тем. Вы сможете найти книгу, направленную на один конкретный язык программирования, но которая также пригодится и для разработчиков на других языках. Также я включил здесь книги, не связанные с разработкой непосредственно, но которые в то же время считаются неплохими для развития особого «программного» мышления.
Короче говоря, без лишних слов – я рад представить:
Список лучшей литературы для разработчиков
7 упоминаний:
Паттерны проектирования: Элементы повторного использования программного обеспечения
«Классическая книга, прочтение которой ознакомит читателя с различными паттернами программного проектирования, а также раскроет некоторые секреты наиболее популярных из них.» Джон Сонмец
«Еще одно произведение классики, содержащее в себе огромную коллекцию различных паттернов программирования.» Лик Бун
Код: Скрытый язык аппаратного и программного обеспечения
«Должна быть в закладках у каждого, кто так или иначе связан с программной индустрией, не важно при этом – программист ли он али нет.» Вуди Леонхард
«После прочтения этой книги вы поймете, что на самом деле выполняет ваш код и как на самом деле этот код исполняет процессор. Это одновременно и весело, и полезно.» Джон Сонмерц
8 появлений:
Эффективная работа с правильным кодом
«Я обожаю эту книгу, так как рано или поздно в один прекрасный момент программисту придётся заниматься поддержкой и разработкой уже существующих комплексных систем.» Джейсон Роял
«Если вы принимаете участие над работой с большим объемным кодом более пяти лет, эта книга, вероятно, станет вашей новой Библией. Прочтите это и примите в свои сердца.» Джон Сонмерц
Люди: Продуктивные проекты и команды
«Эта книга оказала на меня наибольшее влияние в свое время. Пожалуй, я могу сравнить ее с эффектом от прочтения Манифеста Анти-Дилберта.» Джоел Сполски
«Если вы желаете носить гордое звание тим лидера на практике, нежели на словах – эта книга определенно для вас.» Джеф Атвуд
9 упоминаний:
Паттерны разработки корпоративных приложений
«Книга очень полезна при разработке массивных приложений, так как она предлагает детальное объяснение ситуаций, когда нужно использовать определенный программный паттерн (а когда наоборот - нет). Даже не могу назвать примерное количеств раз, сколько мне приходилось обращается к данной книге.» Род Хилтон
«Обеспечивает читателя каталогом качественных проверенных корпоративных паттернов и ситуаций, советует, когда эти самые паттерны стоит использовать.» Иан Джойс
11 упоминаний:
Вступление в алгоритмы
«Пожалуй, это лучшая книга для понимания и использования алгоритмов (которые де-факто являются основным инструментом разработчика программного обеспечения).» Вуди Леонхард
12 упоминаний:
Чистый код: Пособник мастера программного обеспечения
«Если вы пожелаете прочитать книгу, связанную с программированием, определенно – вам стоит обратить свое внимание на эту.» Роберт Грайнер
«Это еще одна книга, которой удалось полностью изменить стилистику написания моего кода. Я могу ясно разделить свою жизнь на период до прочтения книги и после.» Джон Сонмерц
Рефакторинг: Улучшение дизайна существующего кода
«Книга, строго рекомендуемая к прочтению для каждого, кто желает улучшить качество кода.» Деепак Карантх
«Обязательна к прочтению каждому, кто так или иначе принимает участие в работе с объектно-ориентированными языками программирования.» Дэниель Рид
14 упоминаний:
Мифический человеко-месяц, или Как создаются программные системы
«Это классика, но недавно исправленная и дополненная. В высшей степени поразительно то, как она тесно связана с разработкой программного обеспечения. Если вы принимаете участие в программировании, определенно эта книга – обязательна к прочтению.» Джейсон Роел
«Бесспорно, единственная классика, посвященная программированию. Позор всякому, кто еще не прочитал ее.» Джеффри Атвуд
15. упоминаний:
Прагматичный программист: От новичка к мастеру
«Насколько революционна эта книга? Пожалуй, достаточно для того, чтобы развернуть целую издательскую кампанию. Если вы все еще не прочитали ее – это, бесспорно, большое упущение с вашей стороны.» Род Хилтон
«Эта книга не только изменит ваш код: она изменит вас как программиста. Наполненная практическими советами по улучшению вас и вашего кода, бесспорно, является отличным приобретением для каждого, кто хочет стать лучшим в сфере разработки программного обеспечения.» Деепак Карант
16 упоминаний:
Идеальный код: Практическое пособие по программной архитектуре
«Сделайте для себя приятное. Пусть это будет первой книгой, которую вы прочитаете – и первой книгой, которую вы посоветуете другим.» Джеффри Атвуд
«Эта книга потрясла меня больше всего. Определенно, после ее прочтения то, как я писал код, и то, что я думал о программировании в целом, претерпело серьезные изменения.» Джон Сонмец
Полный список содержит в себе 139 книг. При желании на языке оригинала его можно рассмотреть здесь.
Автор перевода: Евгений Лукашук
Оригинал статьи
Мій перший досвід перенесення .NET програми під .NET Core
Автор: Ben Emmett
Мой первый опыт переноса .NET приложения под .NET Core
Совсем недавно я портировал .NET 4.5.2 – приложение под .NET Core 2.0. Хочу сразу отметить, что эта статья не является гайдом, и тем более это не перечень того, что может во время процесса пойти «не так». Однако она призвана дать общее понятие операции, мои впечатления от перехода на Core – стандарт и вообще, а стоит ли это делать.
Приложение
Приложение, которое я портировал, импортирует и обрабатывает информацию от ресурса SurveyMonkey. Проект DataPersistence – это уровень для взаимодействия с базой данных, в моем случае – через Entity Framework 6.2. Логика взаимодействия с SurveyMonkeys и преобразования данных так же, как и различные администрирующие функции, помещены в библиотеке ImporterCore. Importer – это небольшое консольное приложение, которое инкапсулирует определенную функциональность из ImporterCore, позволяя запустить ее в качестве запланированной Windows-задачи. Проект Explorer является веб-приложением ASP.NET MVC 5 для анализа информации. Проект Tests (на диаграмме не представлен) построен с использованием nUnit3 и обновляет все проекты к 5 версии.
Кратко о процессе
Сам порт занял у меня около двух дней. В конце концов картинка была следующая:
Более 80 процентов усилий были затрачены на чтение блогов, логов ошибок и, конечно же, употребление кофе. Но только после всего этого я смог собой гордиться. Впрочем, если бы мне пришлось повторить порт снова, сейчас бы он занял у меня всего лишь одну четвертую от того времени, которое я потратил. Итак, касательно порта я могу сказать следующее:
Просто погуглите готовые решения и применяйте их до тех пор, пока все это дело не заработает снова.
Для всех компонентов, кроме, собственно говоря, самого веб-проекта, обновите csproj-файлы к более новому и упрощенному VS15-формату, который все еще поддерживает версию .NET 4.5.2. Я подумал, что лучше сделать это вручную, чем пересоздавать проекты с нуля.
Выгрузите все проекты из решения отдельно от DataPersistance, которая была в основании пирамиды приложения. Соберите для .NET Core – стандарта.
Обновите все пакеты библиотеки DataPersistence к последним версиям, поддерживаемым .NET Core. В некоторых исключительных случаях (наподобие работы с Entity Framework) полностью замените пакеты программ на .NET Core – аналоги (в нашем случае это будет Entity Framework Core).
Просмотрите все провальные билды и исправляйте все изменения api до тех пор, пока проект не скомпилировался.
Повторите шаги 2-4, добавляя дополнительные пакеты к приложению (по одному за раз).
Чтобы заставить заработать веб-проект после порта, мне пришлось бы столько всего фиксить и исправлять, что я просто предпочел создать новый пустой проект и просто скопировал папку контроллеров, моделей и представлений + различные статические файлы в виде JavaScript и CSS. Перенос сайта на новый проект вместо исправления старого было определенно правильным решением.
Запустите тесты. Запомните, что «построение того же самого, что и раньше» - это не то же, что «делать то же самое, что и раньше».
Исправьте баги шага 7.
Проведите мануальные тесты.
Упущения
К сожалению, далеко не все прошло так гладко, как хотелось бы. В основном замеченные ошибки были связаны с не совсем правильным выполнением шагов 7 и 8.
Несовместимые библиотеки
Дело в том, что ImporterCore зависела от библиотеки, которую я написал несколько лет назад и которая не поддерживает стандарт .NET Core. Она использует WebClient, который не существует в рамках .NET Core 1.0 / 1.1. К счастью, уже в версии 2.0 появилась поддержка WebClient, что значительно упростило обновление системы – нужно всего лишь внести некоторые изменения в csproj, AssemblyInfo и nuspec – файлы. Однако в случае, если вы все же сильно зависите от неподдерживаемых библиотек, порт приложения будет невозможен.
Entity Framework
Эта вещь заняла больше всего времени. Дело в том, что Entity Framework 6.2 в .NET Core не поддерживался, а его аналог – Entity Framework Core – значительно различается, что делает процесс порта достаточно трудоемким. А именно:
Маппинг
В конце концов EF Core мне понравился больше, чем EF 6.2. Здесь я привожу пример оригинального файла маппинга для оригинального объекта – Survey. Здесь Entity Framework получает информацию об именах колонок для всех свойств, названия таблицы, ключевом свойстве.
В EF Core при преобразовании свойства производится маппинг к соответствующей колонке (разве что вы не укажете другую логику маппинга). Также считается, что если в вашем классе вашей сущности есть свойство Id или SurveyId, это будет считаться свойством-ключом (опять же, если вы не укажете обратное). Так что мне удалось избежать написания около 1000 строк лишнего кода, что достаточно круто.
Большинство из оставшихся нюансов маппинга могут быть настроены через аннотации, композитные ключи и так далее.
Изменения в API
Здесь также есть целая серия замечательных изменений. К примеру, для конфигурирования «иностранных» ключей мы писали следующий код:
Однако в EF Core метод HasRequired() заменился на HasOne(). Также раньше для тестов приходилось использовать context.Database.Create() и context.Database.Delete(), которые в EF Core были заменены на context.Database.EnsureCreated() и context.Database.EnsureDeleted().
Наложение
Немного больше усилий пришлось приложить, чтобы настроить кастомную работу со значениями типа DateTime. Приложение всегда сохраняет значения типа DateTime в базе как Utc, но когда EF читает это, указанный тип не распознается, таким образом он маркируется как DateTimeKind.Unspecified, что в последствии может приводить к нежелательным последствиям. В рамках предыдущей версии EF я использовал возможности фичи – Intersection, которая, увы, больше не доступна в полной мере в раках EF Core. Впрочем, я смог решить проблему при помощи использования инструмента EntityMaterializerSource.
Лично меня сводит с ума то, что ни одна версия Entity Framework – технологии не поддерживает в нормальном виде работу с UTC – форматом.
Lazy Loading
Это было наибольшее разочарование: EF Core не поддерживает Lazy Loading. Да, в грядущей версии EF 2.1 эта опция должна появиться, но на данный момент решения не существует. В свое время я написал немного горькой правды о производительности Entity Framework, потому использование возможностей Lazy Loading было бы разумным решением. Отследить правильность работы с базой во время построения приложения невозможно. К счастью, при помощи некоторых тестов мне удалось вовремя заметить, что EF Core не использовал возможности Lazy Loading, но представьте себе, что было бы, если бы я этого не заметил и выпустил приложение в продакшн.
Конечно, решение использовать Eager Loading вместо Lazy Loading не стало концом света, но оно вынудило писать большее количество тестов, усложнило код (в основном из-за использования вложенных Include() и ThenInclude() - конструкций) и слегка замедлило работу. Возможно, с релизом EF Core 2.1 я все же верну все так, как было.
Конфигурация
В то время, как .NET Framework хранит все записи о конфигурации в виде xml в app.config / web.config – файлах, .NET Core использует appsettings.json. Лично мне это понравилось, но вместе с этим мне пришлось внести некоторые изменения.
Хостинг на IIS
Оригинальный веб-сайт Explorer развернут под IIS. ASP.NET Core использует Kestrel, который запускается в качестве отдельного от IIS – процесса. Вам необходимо установить .NET Core Windows Server Hosting Bundle, что позволяет Kestrel непосредственно работать с кодом, а IIS – отвечать за безопасность и некоторые задачи администрирования. Также необходимо настроить пул приложения для запуска неуправляемого кода.
К несчастью, деплой подобного в продакшн – сложный и трудоемкий процесс. Пришлось ждать помощи от дружественно настроенного сисадмина. Упс.
Вердикт
По сути, я не встретил ничего особо страшного. Только парочку незначительных багов, каждый из которых потребовал немного времени на устранение. Для отслеживания подобных багов я советую использовать Portability Analyzer, который значительно упростит вам работу.
Я портировал небольшое приложение – всего лишь 5 проектов с несколькими десятками тысяч строчек кода. Если я буду делать что-то подобное вновь, весь процесс должен занять у меня намного меньше времени, чем пара дней. А в целом перед портированием больших приложений я все же советую пока попрактиковаться на маленьких.
Вообще, если говорить о целесообразности перехода на стандарт .NET Core, я был вынужден это сделать только потому, что нам предстоит взаимодействовать с другими приложениями этого же стандарта. А так, безусловно, новая технология ASP.NET Core заслуживает своего внимания.
Автор перевода: Евгений Лукашук
Источник
ASP.NET Core vs Node.JS
Автор: Guillaume Jacquart
Я работал с .NET-платформой на протяжении 5 лет – как в плане профессиональной необходимости в качестве бек-енд разработчика и архитектора, так и в плане определенных личных задач - таких как открытые и закрытые сторонние проекты.
После нескольких лет работы с экосистемой PHP и имея солидный стаж в плане Java, я пришел к выводу, что язык C# для меня представляет, пожалуй, наибольший интерес – благодаря своему удобству и эффективности. Этот язык комплексный, тщательно продуманный и лично для меня в работе с C# лучшую среду программирования, нежели Visual Studio, человечество еще не изобрело. Более того, ASP.NET уже содержит в себе все, что необходимо веб-разработчику, не требуя установки дополнительных фрейморков и библиотек.
Единственное, что меня не очень устраивало в плане .NET-системы, это ее «закрытость» и использование преимущественно Microsoft-платформы (хотя и существуют специальные Mono, которые позволяют в качестве альтернативы запускать шарп-проекты и под Linux, но достигается это ценой утраты целого ряда полезных фичей).
По этой причине я обратил свое внимание на Node.JS, хотя мои коллеги называли JavaScript бесполезным языком, а Node.JS – хламом. Я был очарован однопоточной каллбэк-системой, я наслаждался, создавая REST API, используя ExpressJS.
Но затем Microsoft выпустила кроссплатформенную технологию ASP.NET Core, и я призадумался, что же и когда стоит использовать.
После чего я решил собрать как можно больше информации касательно возможностей и реализации тех или иных фичей двух технологий, после чего выбрал для себя, по моему мнению, наиболее удобную технологию, в рамках которой и развернул свой новый проект. Надеюсь, эта публикация вам тоже поможет прийти к определенному решению.
Модель обработки запроса
Node.JS
Node.JS успел зарекомендовать себя как однопоточный обработчик запросов. Что это значит? Это значит, что вместо обработки каждого поступившего http-запроса внутри отдельного потока или процесса (наподобие Apache), обработка производится внутри одного потока.
Подобный подход делает обработку запросов однопоточной, тогда как в Apachi\PHP обработка является многопоточной. Однако, что касательно Node.JS, здесь преимущество заключается в асинхронной работе системного ввода-вывода, которое, соответственно, не блокирует требуемый поток. Операция ввода\вывода производится в рамках отдельного потока, в то время как основной продолжает свою работу. Как только вторичный поток завершает свою работу, вызывается callback, который, соответственно, передает в контекст основного потока результат.
С одной стороны, использование подобного подхода прекрасно подходит для приложений, интенсивно работающих с вводом\выводом. С другой стороны, появляется вероятность так называемого «ада обратных вызовов», который провялятся в цикличной сложности кода. Будем надеяться, что новая версия введёт в обиход полноценные async\await.
Однопоточная модель обработки запросов Node.JS может быть сгруппирована при помощи использования нативной кластеризации, Nginx или PM2.
ASP.NET (синхронный)
Исторически так сложилось, что обработка запросов ASP.NET MVC (или Web Api) производится подобно Apache / PHP: каждый запрос обрабатывается внутри своего собственного потока пула потоков. И каждая команда ввода-вывода производится синхронно внутри каждого из потоков.
В контексте жесткой работы с вводом-выводом подобный подход, конечно, менее удобный, если сравнивать со схемой Node.JS.
Хвала Небесам, .NET Framework 4.5 вводит в C# async\await, что также исправляет сложившуюся ситуацию.
ASP.NET Core (асинхронный)
Паттерн async\await позволяет в полной мере ощутить все прелести асинхронного программирования. Действительно, теперь появилась возможность указать каждый обработчик запросов как асинхронный, благодаря чему работа с системой ввода-вывода будет производиться в контексте своего потока. Это позволит не блокировать основной поток.
Подобная модель на базе Task`ов позволяет использовать обратные вызовы, ощутить все прелести асинхронности и прочее.
.NET Core часто применяет паттерн async\await при интенсивной работе с системой ввода-вывода.
Async\await Node.JS VS Async\await ASP.NET Core
Пример кода Node.JS для асинхронного запроса в базу данных:
Пример того же кода на ASP.NET Core (фрагмент класса Startup):
Разница между двумя моделями в том, что ASP.NET Core способен обрабатывать большее количество запросов благодаря своей дефолтной параллельности. В то же время переключение между асинхронными потоками может занимать время в случае использования большого количества общих для многих потоков переменных. В такой ситуации все же Node.JS будет быстрее.
Много современных языков программирования, вроде того же C#, реализуют асинхронный ввод-вывод, который часто недооценен сообществом Node.JS-разработчиков, но который может приводить к приятным неожиданностям.
В этом случае Node.JS в значительно меньшей мере технологичный, если сравнивать его с ASP.NET Core.
Язык программирования
Особенности и безопасность
Вращаться в среде C#-разработчиков – значит выслушать множество критики в адрес динамической типизации и удивительных булевых преобразований JavaScript. Впрочем, эта критика является обоснованной, если учитывать, что JavaScript был разработан всего за 10 дней для динамического контента HTML.
С другой стороны, с того времени язык очень даже «вырос», и новая спецификация привносит такие фичи, как:
Классы
Новые идентификаторы (const, let), повышающие надежность кода
Указательные функции
Интерполяцию строк
Генераторы
Элементы рефлексии
Впрочем, C# все равно остается намного более мощным языком программирования, ибо все вышеперечисленное – всего лишь небольшая часть того, чем может похвастаться строго-типизированный объектно-ориентированный язык программирования. Мне кажется, что для C# лучшей среды работы, нежели Visual Studio, просто не найти.
Однако, если учитывать рост спроса на рынок микросервисов, большинство из особенностей подобных гигантов здесь не найдут свое применение.
Изучение
Если вы раньше работали с классической MVC-архитектурой, переход на Node.JS \ Express затребует некоторое время, чтобы привыкнуть. Некоторые же вещи могут вообще оказаться в новинку. Также нужно будет время для того, чтобы «переварить» событийно-ориентированную парадигму Node.JS.
Что действительно может показаться запутанным впервые при работе со средними или большими приложениями, так это паттерны рефакторинга кода и, собственно говоря, архитектура кода. Так как функциональность Express.js очень гибкая, выбор «правильной» архитектуры и файловой структуры может быть затруднительным. С другой стороны, для создания качественного приложения без этого – никак.
Что же касается ASP.NET (Core) MVC / WebApi, то тут уже предоставляется готовая файловая структура. Да, разработчик может применить немного «креативности» при создании бизнес-логики и слоя для работы с базой, но предопределенность архитектуры упрощает разработку.
Однако, в случае с маленькими приложениями, JS-платформа более предпочтительна, так как позволяет написать сайт-визитку с использованием одного лишь js-файла и одного лишь package.json.
Продуктивность
Я обнаружил, что написание простого кода является более быстрым при использовании Node.JS. Причина в том, что простые приложения тут проявляют большую «гибкость».
Также возникают вопросы касательно типизации языка, так как в некоторых случаях оказывается, что динамическая типизация является скорее плюсом, чем минусом.
С другой стороны, я заметил, что при написании объемного кода, более читабельным он оказывается при работе с C#, чем с JavaScript. Думаю, причина этому – строгие ооп-парадигмы.
Что касается отладки и юнит-тестирования, тут C# / Visual Studio также показывают лучшую продуктивность, хотя и сказать, что JavaScript совместно с Visual Studio Code пасет задних, нельзя. Время построения маленьких js-приложений также меньше.
Екосистема
В этом плане две технологии отличаются больше всего. Node.JS обязана своим развитием в основном сообществу, которое и разработало для неё большее количество существующих популярных библиотек.
С одной стороны, вы чувствуете себя очень свободно в выборе модулей для разработки. С другой же, внезапное обновление одного из пакетов, отсутствие надлежащей проверки на ошибки и стабильность, в некоторых случаях могут легко привести к обвалу всего приложения.
ASP.NET Core технология разработана проверенной командой профессионалов из Microsoft. И она предоставляет абсолютно все, что необходимо разработчику веб-приложений любых направлений. Кроме того, сторонние библиотеки также качественно выполнены и разработаны другими крупными проверенными компаниями.
Один из многочисленных примеров – ORM-инструменты. Entity Framework, официальный инструментарий для работы с базой данных, предоставляет абсолютно все, что необходимо разработчику.
Публикация и запуск
А вот это та область, где Node.JS, без сомнения, лидирует. Технология является открытой, кросс-платформенной, поддерживает докеризацию. Это значит, что вы запросто сможете запустить свое приложение под такими платформами:
На собственном Linux, Windows или Mac-сервере. Все, что для этого нужно – это движок Node.JS и реверсивный прокси-сервер (наиболее популярный – Nginx).
Докер-контейнер.
Большинство PaaS-провайдеров (AWS, Google App Engine, Azure, Heroku, …)
Сервис Now, который позволяет провести запуск Node.JS-приложения в одну строчку без предварительной конфигурации.
Также есть много подходящих CI & CD – платформ.
Что же в случае ASP.NET-стека, тут все обстоит несколько печальнее. Хотя и ASP.NET Core также кросс-платформенная, количество сервисов для публикации несоизмеримо меньшее.
Вот какие хостинги я знаю на данный момент:
Собственный Windows-сервер с классическим IIS.
Собственный Linux-сервер с реверсивным прокси.
Докер-контейнер под Windows. Работает отлично, но занимает много места.
Некоторые облачные сервисы PaaS. В основном, Azure, но есть также некоторые неофициальные билды Heroku.
Заключение
Node.JS обладает асинхронной событийно-ориентированной моделью обработки запросов, которая не очень то и уступает многопоточной async\await модели ASP.NET.
Производительность Node.JS – приложений не всегда лучше, чем ASP.NET Core. Можно сказать, она даже хуже.
Язык JavaScript не так уж и плох (и становится лучше!). А использование его вместе с Node.JS может дать приятный результат.
ASP.NET (Core) лучше всего подходит для объемных приложений и предоставляет все необходимые разработчику инструменты высшего качества.
Для микро- или среднеразмерных сервисов Node.JS предоставляет широкие возможности в плане публикации.
И, как всегда, не существует одного лучшего инструмента «на все случаи жизни». Попробуйте доступные и подберите для себя тот, который лучше всего отвечает вашим требованиям.
Автор перевода: Евгений Лукашук
Источник
Коли потрібно переходити на ASP.NET Core?
Автор: Steven Smith
Прошло много времени с момента релиза ASP.NET Core 1.0. Затем появились версии 1.1, 2.0… В общем и целом серверные компоненты и технология оказались достаточно качественными, в них было замечено всего лишь несколько багов. Кроме того, начиная с вышеупомянутой версии 1.1, было добавлено бессчётное множество различных полезных примочек к Entity Framework Core и самой ASP.NET Core. Помимо прочего, стоит также отметить радикальные отличия в структуре проектов, которые могут показаться слегка непривычными, но являются жизненно необходимыми для взаимодействия проектов .Net Core с другими типами проектов. Но ожиданиям качественного инструмента пришел конец. Произошел релиз Visual Studio 2017, и она успела зарекомендовать себя как достаточно стабильная версия. К тому же я без проблем сумел перенести мои проекты на базе project.json в новый формат файлов MSBuild без всяких проблем. Помимо прочего, стоит также отметить целую серию приятных улучшений стандартной среды языка .NET. Мы долго ждали и дождались – наконец-то стандарт .NET Core (вместе с технологией ASP.NET Core) успешно захватывает IT-рынок и обладает целым рядом полезных инструментов для разработки. Если вы из компании, которая от стольких лет ожидания успела натереть себе мозоль – определенно, вам есть чему радоваться.
Итак, ASP.NET Core сейчас уже на полках. Так в каких случаях нам стоит забыть про старый добрый ASP.NET и опробовать его кроссплатформенную версию? Позволю себе поделиться мнением.
Новые проекты
Если вы начинаете разработку нового проекта с использованием MVC-подхода и/или Web API, вам определенно нужно обратить свое внимание на ASP.NET Core. Технология содержит в себе целую серию значительных улучшений, которые заметно отличают ее от предшественницы. Помимо прочего, она также может похвастаться первоклассной системой внедрения зависимостей. ASP.NET Core также обладает специальными tag-helper`ами. Используя сервис TestServer, вы запросто сумеете производить локальные тесты прямо на свое ПК (забудьте про падения через неверную конфигурация фаервола). Web API теперь внедрены в ASP.NET Core MVC, потому теперь нет никакой необходимости использовать сторонние библиотеки с кучей дублирующих компонентов. Также скорость работы значительно выше, плюс, помимо прочего, арсенал может похвастаться значительно большим количеством опций, нежели MVC5/WebAPI2, который в значительной мере привязан к IIS.
Но что, если проект имеет среди зависимостей сторонние библиотеки (собственные или чьи-то еще), которые требуют полноценной среды .NET Framework, не включенной в .NET Core?
Нет никаких проблем. При желании в ASP.NET Core можно включить полноценный .NET Framework. Желаете использовать ваш Entity Framework 6 или NHibernate для работы с данными? Да ради Бога. Все прекрасно будет работать и в ASP.NET Core. Единственное, что вы от этого утратите – это кроссплатформенность, ибо эти сервисы могут быть запущены только в рамках Windows-сервера.
У меня нет времени переучивать команду на ASP.NET Core!
На счастье, переход на новую платформу не займет много времени, если ваша команда уже знакома с ASP.NET MVC и/или Web API. Концепция Core – использовать все, что было раньше, но значительно лучше. Контроллеры и представления никуда не делись. Представления все еще используют Razor. Маршрутизация по сути своей осталась прежней – она даже стала немного проще. Фильтры также особо не изменились, а Web API добавили своего удобства в использовании (так как они были интегрированы в MVC). Конечно, отличия все же есть, но это не критично. Несколько новых вещей, вроде того, как запускается приложение или как работает middleware, выучить придется, но в целом опыт работы на предыдущей ASP.NET Core MVC тут будет решать очень многое.
Я хочу поместить приложение в контейнер на Linux!
Тогда вы можете желать только ASP.NET Core. Вы не сможете использовать библиотеки из среды .NET Framework, но что касательно стандартных компонентов .NET Core – полный вперед. И да, вы также можете помещать свои приложения под Azure на Linux.
Судьба приложений на ASP.NET MVC 5 и/или Web API 2
Предугадать тут что-либо конкретное будет несколько затруднительно. Если эти приложения работают и запускаются без проблем, не думаю, что необходимость переходить под ASP.NET Core такая уж срочная. Однако, несколько причин, по которым стоит интегрировать подобные программы под ASP.NET Core, все же есть:
Сама поддержка. Если вы бы хотели деплоить приложение и его сервер вместе, без привязки к IIS – Core, – это однозначно ваш выбор.
Поддержка различных платформ. Порой использование Windows-ориентированных серверов может быть дороже прочих других. Возможно, вы могли слышать об поддержке контейнеров, Докера и так далее. Core все это поддерживает – причем на очень даже приличном уровне.
Множественные приложения. Приходилось ли вам запускать несколько экземпляров приложения на одной и той же машине? ASP.NET Core позволит это делать значительно удобнее и эффективнее, нежели традиционный ASP.NET.
Тестирование и Domain-Driven Design (DDD). Если ваша команда следует этому подходу, пишет тестируемое программное обеспечение, то ASP.NET Core (и Entity Framework Core) привнесёт целый ряд полезных фич, которые значительно могут упростить жизнь.
Программы Web Forms
Если ваше приложение базируется на веб-формах, возможно, вам лучше всего будет оставаться на ASP.NET. Microsoft активно инвестирует в эту технологию. Существует множество способов улучшить качество кода, используя внедрение зависимостей и прочее. Но смена платформы на ASP.NET Core MVC будет такой же «болезненной», как и переход на ASP.NET MVC 5,4,3,2,1. Что хуже, используя MVC 5, вы можете запускать страницы отдельно друг от друга, но проделать подобное с ASP.NET Core не представляется возможным. Лично я могу посоветовать оставаться на веб-формах до тех пор, пока приложение не потребует полноценной замены. В плане нагрузки на данные, потребовалось бы применить стиль SPA-приложений со значительно большим количеством клиентского кода и фрейморков типа Angular 2, или React.
Другие размышления
Хотя Visual Studio – прекрасный инструмент для разработки приложений, эта среда не бесплатная (за исключением комьнити-версии). Помимо прочего, она Windows-ориентированная (да, есть VS для MacOS, но это совершенно другое приложение). Если же студия для вас по причине цены или размеров неприемлема, .NET Core будет воистину полезным приобретением. Вы можете на MacOS, Linux (и, разумеется, под Windows) работать в Visual Studio Code!
Подобным образом, если ваши приложения больше ориентированы на клиентскую часть, ASP.NET Core порадует более облегченными размерами. В то время, как фронтендеры превозносят NodeJS как быструю технологию (и ее возможность исполнять js-код на сервере), ASP.NET Core может также исполнять Node.JS на сервере (и вы также можете работать под JS на сервере, если вам захочется). Используя TechEmpower, ASP.NET Core, развернутый с использованием Kestrel, может обрабатывать до 1 миллиона запросов за секунду на том же ПК и в рамках того же приложения, в то время, как NodeJS обрабатывает всего около 175 тысяч в секунду.
Подведем итоги
Безусловно, ваш опыт и ваше мнение может сильно отличаться от моего, потому вопрос о том, стоит ли переходить на ASP.NET Core для некоторых может остаться открытым. И, конечно, ASP.NET Core далеко не единственная технология, используя которую вы будете создавать свое следующее веб-приложение. Однако, тема этой статьи как раз-таки ASP.NET Core, с которым мне приходилось долго проработать. К тому же, написано очень много официальной документации на официальном сайте Microsoft. Я не советую переходить на ASP.NET Core лишь потому, что он такой новый и весь из себя красивый. Решение перейти должно быть тщательно взвешенным и подкрепленным весомыми аргументами, которые я постарался привести в своей статье.
Что дальше?
Разработка ASP.NET Core продолжается. Уверен, версия 2.0 – далеко не последняя! Было бы неплохо взглянуть на обновленный SignalR и новую функциональность разор-страниц.
Автор перевода: Евгений Лукашук
Оригинал статьи