Nuxt as fullstack server: frontend + backend api server (часть 1)

Содержание

Кейс 3. Контролируем эксплуатацию

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


Я знаю, что передача проекта в эксплуатация довольно часто выглядит следующим образом.

Фронт: Ребят, я всё сделал. Код в репе. Выкатите, плиз!Админ: Как оно выкатывается?Фронт: Собираешь нодой и раздаёшь статику веб-сервером из папки Админ: Какой версией ноды собирать? Какая команда сборки? Каким веб-сервером раздавать?

В итоге для админа развёртывание вашего проекта превращается в не менее увлекательный квест, как для вас развёртывание API на локальной машине из предыдущих кейсов.

Даже если проект будет работать у вас на компьютере, совсем не обязательно, что всё так же будет работать на продакшене. И мы получаем классическую проблему «это работает на моей машине».

Docker помогает нам и с этим. Решение простое, если мы запаковали наш проект в Docker, тем самым автоматизировав его сборку и настроив запуск, то он будет одинаково работать на всех серверах, которые поддерживают Docker.

А инструкция для админов сведётся к:

Фронт: Ребят, я всё сделал. Собрал для вас Docker-образ. Выкатите, плиз!Админ: Ок

Уж с чем, а с Docker-образами админы точно должны уметь работать. Не то, что с нашей нодой.

Время простоя (downtime)

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

Вы должны различать какие запросы в вашем приложении являются критичными, когда нужно показать полноэкранную ошибку с сообщением «Попробуйте позже», а когда ошибку можно обработать с помощью постепенной деградации (например серая кнопка для какой либо функции, с сообщением при наведении о том, что функция на текущий момент недоступна)

Если ваш бэкэнд разделен на несколько микросервисов, вероятность сбоя подмножества эндпойнтов выше. В другом случае, eсли ваш бэкэнд представляет собой только один сервер, один сбой может разрушить все эндпойнты.

В любом случае, хороший фронтэнд должен всегда отлавливать ошибки в запросах с помощью try catch и иметь заготовленные ошибки для пользователя. В javascript нет встроенной функции(recovery panic), которая позволяет продолжить выполнение кода после ошибки, поэтому при её возникновении ваше приложение упадет.

Любопытные ожидания других людей, с которыми пришлось сталкиваться

— Хочу кодить

— Но ты же фронтендер

Реальность: современный фронт это далеко не только вёрстка или кусочки кода для анимации. Это полноценная разработка и программирование, причём иногда не только на JS.

Ожидание: браузер один или они все одинаковые

Реальность: браузеров много и они все разные

Сейчас эта проблема не так ярко выражена, как, например, во время моего вхождения в сферу. Когда для разных браузеров подключались разные стили, руками проставлялись префиксы в больших количествах, а для простой выборки элемента в JS требовалось писать три различных варианта кода под IE, Safari и Opera. Стандартизация понемногу побеждает, и это круто. Но забывать о кроссбраузерности ещё рано.

Что такое frontend и backend

Frontend отвечает за то, что пользователь может увидеть в браузере — веб-сайты и приложения. В него включены технологии: HTML, CSS, JavaScript.

Языки программирования: frontend

Помимо перечисленного, существуют фреймворки: Angular, React, jQuery, Bootstrap, Vue, Backbone.js, Prototype, MooTools, Ext JS, Knockout, Underscore.js, Ember.js, Lodash, Lodash. Все они в разной степени популярны, что можно увидеть на статистике от Tproger, 2018 года:

Рейтинг популярности frontend-фреймворков

На графике видно, что лидирует React, так как наибольшее число людей попробовали его и хотят продолжить с ним работать. Лидирующие позиции также занимают Angular и Vue. 

Backend — то, что происходит на сервере. Благодаря нему формируются API, использующиеся для функционирования фронтенда. Примеры таких языков: PHP, Python, Node.js.

Языки программирования: backend

Но таких языков много, например:

  • Ruby;
  • Java;
  • Perl;
  • Scala;
  • .NET.

Стоит упомянуть фреймворки для этой области IT: Django, Yii, Zend Framework, Symfony, Ruby on Rails, .NET Framework, Drupal CMF, Laravel, Kohana, CakePHP.

Фронтенд и бекенд четко разделены — JavaScript-программисту не обязательно хорошо разбираться в серверной части сайта и наоборот. Тем не менее, знания из смежных областей сильно помогают в IT — разработчику легче коммуницировать с коллегами и понимать происходящее на проекте.

Также существуют fullstack специалисты — они овладели обоими направлениями и могут или создавать продукт в одиночку, или просто сильнее включаться в проект. У таких сотрудников могут быть свои недостатки, но от этого они не теряют востребованности.

И не забывайте развлекаться

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

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

Благодарю за прочтение. Я надеюсь, что вы воспользуетесь карантином как возможностью для роста и обучения. Берегите себя и наслаждайтесь временем, проведенным дома.

P.S. от переводчика:

Спасибо за внимание!

Выходим за пределы серверной части

Вот где действительно становится интересно. Почти все браузеры начали реализовывать в себе движки JavaScript. На мой взгляд, именно AJAX изменил ход веб-приложений. Google первым освоил его с помощью своего почтового клиента и картографических приложений.

Мир серверной MVC, генерирующей HTML + JavaScript. Код JS разбросан по страницам. JavaScript в основном используется для улучшения UX за счет сокращения циклов просмотра сервера (Server View Cycles). Такие вещи, как отправка формы, проверка ввода и т.д. обрабатываются клиентским кодом.

Это самая распространенная архитектура в истории веб-приложений. Большинство приложений B2C, SEO-дружественных веб-сайтов, особенно созданных с помощью CMS — Content Management Systems, используют его. Количество клиентского кода зависит от потребностей приложения.

Эта архитектура как таковая никогда не была действительно стандартизирована и поэтому не имеет названия. Она развивалась инкрементном стиле и до сих пор считается расширением Web MVC. ASP.NET MVC, Java Struts, Python Django, Ruby ROR, PHP CodeIgniter — некоторые из широко используемых сред, широко использующих серверную MVC или Web MVC.

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

Как взаимодействуют frontend и backend разработчик

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

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

  • ошибка непосредственно сервера;
  • в данных не окажется чего-то необходимого;
  • данные неправильно передаются.

Фронтендер не может поправить это — он говорит о проблеме человеку, занимающемуся бекендом, а тот решает данный вопрос. Стоит отметить, что такое взаимодействие происходит только в ситуации, когда между программистами нет прослойки в виде project manager, техлида или тимлида. При их наличии веб-разработчикам не нужно общаться между собой — коммуникация идет через специалистов, они же дают всевозможные указания, ищут компромиссы, продумывают архитектуру. Так происходит в больших командах, где роли распределены и четко разграничены — сотрудники полностью сосредоточены исключительно на своих небольших секторах обязанностей и максимально продуктивны.

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

Таким образом можно добиться наиболее эффективного взаимодействия, избежать недопониманий.

Учебные ресурсы

Фронтенд

  • Responsive Web Design Certification (freecodecamp.org)
  • Beginner JavaScript (beginnerjavascript.com — Wes Bos)
  • React Tutorial for Beginners (youtube.com — Programming with Mosh)
  • Front End Masters (frontendmasters.com)

Бэкенд

  • APIs and Microservices Certification (freecodecamp.org)
  • Super simple start to serverless (kentcdodds.com)
  • AWS Certified Cloud Practitioner Training 2019 – бесплатный 4-часовый видеокурс (freecodecamp.org)
  • CS50’s Introduction to Computer Science (edx.org)

Для обоих направлений

  • How to Become a Full Stack Web Developer in 2020 (colbyfayock.com)
  • Egghead.io (egghead.io)
  • 100 Days of Code (100daysofcode.com)
  • The Web Developer Bootcamp (udemy.com — Colt Steele).

Что говорит статистика

Какие технологии и инструменты чаще всего используют фронтенд-разработчики? Во-первых, трудно представить фронтендщика, не умеющего в JavaScript. Это подтверждают опросы:

  • по данным StackOverflow, JavaScript в списке инструментов фронтенда лидирует с огромным отрывом (90,5%)
  • исследование компании O’Reilly, проведенное среди европейских программистов в конце 2016 года, тоже ставит JavaScript на первое месте.

Далее идут различного рода фреймворки и библиотеки, самые популярные из которых: Angular, Node.js, React. Кроме обязательного JavaScript, фронтенд-разработчики также используют и другие языки, хоть и не так часто. Лидируют PHP, SQL, Java и С#. И, конечно же, не обойтись фронтендщику без навыков работы с CMS. Самый популярный выбор — WordPress.

Данные StackOverflow

Если сгруппировать самые популярные инструменты в стеки, то получим такую ситуацию:

А набор самых популярных фреймворков и библиотек всех разработчиков выглядит следующим образом (см. иллюстрацию). Приятно видеть среди этого списка инструменты фронтенда:

Данные StackOverflow

Роли, разрешения и контроль доступа

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

Запутались? Объясню подробнее. Смысл слоя, отвечающего за авторизацию, — это выдача разрешений, поддержание безопасности личной информации, отказ в доступе к конкретным действиям и, где требуется, аннулирование привилегий, чтобы одни пользователи не пробирались в аккаунты других и не смотрели их личные фотографии. Логика разрешений проста:

Пользователь x может сделать действие y с объектом z.

Применим это в конкретной ситуации: Шэрон — редактор и может редактировать посты. Тогда надо определить:

  • роль Шэрон — редактор;
  • ее действие — редактирование;
  • объекты, с которыми она может это делать, — посты.

Как это работает? Просто: булевы переменные. Вы возвращаете True/False в зависимости от того, что и кому разрешено делать с конкретным объектом. Итак, может ли Шэрон редактировать какой-то конкретный пост? Вернуть True, если она редактор, вернуть False и закрыть доступ к посту, если нет.

MVVM — Model View ViewModel

MVP великолепен, и для него есть много возможных вариантов и сложных деталей, но с точки зрения фронт-энда MVVM действительно выделяется. В некоторых реализациях он также известен как Model-View-Binder. MVVM очень похож на Passive View MVP, но с добавленной особенностью привязки данных (data binding). Это техника программирования, которая связывает данные поставщика и потребителя вместе и синхронизирует их. Она избавляет от большого количества стандартного кода, который нам традиционно необходим для синхронизации View и Model. Это позволяет работать на гораздо более высоком уровне абстракции.

С точки зрения связей:

  1. ViewModel — это объект, который предоставляет связываемые (bind-able) свойства и методы, которые используются View.

  2. MVVM имеет дополнительный элемент Binder, который отвечает за синхронизацию View с ViewModel. Каждый раз, когда свойство ViewModel изменяется, Представление автоматически обновляется, чтобы отразить изменения в пользовательском интерфейсе.

Мы еще раз вернемся к привязке данных в разделе веб-приложения.

Программы для версионизации

Чтобы не сталкиваться с проблемой случайного удаления кусков кода, программисты используют версионизаторы. А ещё они помогают команде без проблем работать над одним функционалом совместно.

Часто выбирают систему контроля версий Git без графической реализации. Однако работать через командную строку неудобно и муторно, здесь слишком много нюансов и проблем. Например, возникающие при слиянии файлов конфликты гораздо лучше решать в графическом интерфейсе, чем в консоли.

1. GitKraken — платная программа. Предназначена для Ubuntu и macOS.

2. Tortoise — вариант для Windows, правая рука backend-разработчика.

3. Ещё одно решение кроссплатформенного версионизатора — программа от Atlassian.

Компания предлагает нескольких передовых и надёжных продуктов для разработки, поддержки, управления кодом и рабочими задачами — не только техническими. Конкретно для работы с Git есть бесплатный клиент Sourcetree. Его выбирают, если по каким-либо причинам GitKraken и Tortoise не подходят.

.NET (C#, VB)

Фреймворк с открытым исходным кодом ASP.NET от Microsoft используется для создания веб-сайтов с помощью таких языков, как Visual Basic (VB), C#, F# и других.

.NET работает на основе архитектурного шаблона MVC (Model-View-Controller, Модель-Представление-Контроллер). Контроллер принимает запросы пользователя и взаимодействует с моделью для обработки данных. Затем результат передаётся в представление и отображается в виде интерфейса веб-страницы.

Выложенный в открытый доступ в 2016 году, .NET может интегрироваться с iOS, Linux и Android через .NET Core. Он очень стабилен и надёжен, что делает его популярным выбором для бизнеса. Поскольку .NET — продукт Microsoft, у него достаточно хорошая поддержка.

C#

C# — высокоуровневый язык программирования. Это означает, что разработчики могут писать на нём программы, независимые от архитектуры процессора конкретного компьютера.

C# популярен среди разработчиков, потому что он обладает некоторыми преимуществами C++, но на нём проще писать код и избегать при этом грубых ошибок.

VB

Visual Basic — это потомок BASIC, который унаследовал его стиль и сочетает в себе элементы ООП. Это простой язык для начинающих: он широко распространён и обладает несложным синтаксисом. VB часто применяют для прототипирования. Недостатком программирования на VB является большой объём памяти, необходимый для установки и запуска инструментов разработки.

Что можно делать на .NET

С помощью .NET вы можете:

  • создавать настольные приложения;
  • создавать мобильные приложения;
  • создавать веб-приложения и игры;
  • работать с большими данными;
  • и ещё много чего.

Структура взаимодействия бэкенда и фронтенда


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

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).

Когда страница загружена в браузере, HTML определяет, что будет показано, CSS — как это будет выглядеть, а JS — всякие особые взаимодействия.

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON.

Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения

AJAX позволяет вам загружать данные без обновления страницы. Больше всего это используется в таких фреймворках, как Angular и Ember. После сборки такие приложения отправляются в браузер, и любой последующий рендеринг выполняется на стороне клиента (в браузере).

Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения

Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.

В этом случае для связи фронтенда с бэкендом приложение использует и AJAX, и обрабатываемый на сервере HTML.

Третий этап: сопутствующие технологии — 4 месяца

Далее мы подходим к самой размытой части нашего плана — к многообразию сопутствующих технологий, и не только в области бэкенда, а программирования и разработки вообще. Разработка программного обеспечения безгранична, и ваши дальнейшие действия будут зависеть от ваших потребностей (или потребностей работодателя). Изучили Laravel или он вам просто надоел — изучайте Symfony, этот фреймворк не менее востребован. Захотели немного во фронтенд — изучайте JS, Angular, React, да хоть jQuery. Захотели изучить что-нибудь за пределами REST API — вебсокеты и GraphQL ждут вас. Хотите попробовать NoSQL, чтобы хранить документы, которые в обычную БД без боли не засунуть, или хранить настолько разрозненные данные, что никакой SQL не справится, — берите MongoDB или Redis и разбирайтесь до посинения. Хотите узнать, что такое поисковые движки и как у «взрослых дядь» работает текстовый поиск, — ElasticSearch и Sphinx к вашим услугам.

Обязательно изучите Docker — систему упаковки приложения для более удобного деплоя. Чем это может быть полезно для домашнего проекта? Если вы захотите сменить версию PHP или вообще язык, вам не придется что-то ставить на рабочую машину: достаточно поменять конфиги Docker, и приложение запустится без вашего участия. А еще немного поможет с пониманием, как взаимодействуют между собой отдельные части приложения: фронтенд, веб-сервер, бэкенд, база, что такое отдача статики (картинок и шрифтов). Таким образом, Docker позволяет не зависеть от окружения на сервере, от окружения на рабочем месте, упрощает сборку и развертывание проекта, повышает безопасность работы за счет изоляции всех частей приложения, в том числе и друг от друга. Маленький совет: если вы до сих пор работали на Windows, то настало время разобраться с Linux. Потому что Docker и Windows очень плохо дружат.

Если за год вы освоили все вышеописанное — я вам честно аплодирую. Потому что лично я в своё время освоил не всё из этого списка. Если не получилось, не отчаивайтесь и не спешите посыпать голову пеплом — все учатся по-разному.

CRUD — Create, Read, Update, Delete

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

Frontend developer (Vue)

Sportmaster Lab, Липецк, до 130 000 ₽

tproger.ru

Вакансии на tproger.ru

Но что такое ресурс? Если вы создаете книжный магазин, то книги — это ресурсы. Если вы создаете группу, она сама и есть ресурс и ее участники тоже ресурсы. А также каждая запись или аккаунт, который они используют. Например, это может быть официальное письмо к правительству, открытка или фильм, который они пытаются купить.

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

  • как создавать новые данные;
  • как их редактировать;
  • как их обновлять и удалять.

Так выглядит CRUD при работе с фреймворком Ruby on Rail, который предоставляет слой объектно-реляционного сопоставления (Object Relational Mapping — ORM):

Также ваши ресурсы редко существуют в изоляции. Чаще всего они связаны какими-то отношениями или ассоциациями с другими ресурсами. Давайте взглянем на сценарий, где вы хотите сохранить информацию о парах, которые есть у студента. Вы можете создать дочерний ресурс в  и сохранить его:

Не правда ли, это выглядит и читается, как обычный английский? Но учиться все равно придется, ведь в реальности задачи очень быстро обрастают трудностями! Поэтому вам нужно научиться работать с базами данных, выбрав для себя подходящую модель: реляционную или NoSQL.

Заметьте, что для задач CRUD вам также нужно будет научиться проверять входящие данные и сверяться с разрешениями, прежде чем вы сделаете что-то с этими данными.

Frontend или backend — что выбрать новичку

Выбор зависит от предпочтений человека. Если он предпочитает деятельность, плоды которой можно «пощупать», то это скорее фронтенд, ведь он позволяет сразу же видеть изменения на сайте. Противоположный выбор подходит тому, кто хочет работать с серверными данными — брать HTML файлы, которые уже создал фронтенд-разработчик, и настраивать их передачу на сервер, а также хранение, обработку, сортировку, вычислительные действия.

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

Сложно найти дополнительную мотивацию в размере заработных плат, так как в обоих направлениях они примерно одинаковы.

По данным Dou за декабрь 2018, JavaScript является одним из наиболее популярных языков.

Уровень заработной платы специалистов по JavaScript

По графику видно, что зарплаты выше в Киеве, кроме ситуации с Middle — для них более выгоден Львов. ЗП сотрудников уровня Senior в Харькове и Львове равны.

Уровень заработной платы бекендеров: PHP, Python, Ruby

Зарплаты бекенд-программистов и фронтенд-специалистов находятся на одном уровне. Значительные отличия заметны только у сотрудников уровней Middle и Senior в PHP.

API

Чтобы ваше приложение стало по-настоящему популярным, вам надо начать делиться данными с другими приложениями. Например, вы — музыкальная компания, и вы хотите, чтобы стриминговые сервисы типа SoundCloud поставляли ваш контент, а пользователи могли покупать вашу музыку напрямую из их приложения. Здесь и нужен API.

Термин API — аббревиатура от Application Programming Interface (интерфейс программирования приложений) — применяется к инфраструктуре, которая позволяет другим приложениям взаимодействовать с вашим. На картинке выше вы видите пример применения API для обслуживания сети из многих мобильных и настольных клиентов.

Основные этапы написания API:

  1. Создать API-сервер. Этап подразумевает обеспечение защищенного доступа к ресурсам, которые вы хотите передавать клиентам. Если у вас книжный магазин, то ваш API будет предоставлять названия книг, цены и информацию об издателе другим сайтам и перекупщикам.
  2. Защитить сервер, используя идентификаторы приложений и секретные ключи.
  3. Сделать понятную интерактивную документацию, которая позволит другим разработчикам просматривать ее и взаимодействовать между собой и с вами.

С чего начать

Глав­ный инстру­мент бэкенд-разрабочика — язык про­грам­ми­ро­ва­ния. Здесь у бэкен­да два глав­ных язы­ка:

  • PHP, на кото­ром сде­ла­ны почти все совре­мен­ные веб-движки;
  • Python, на кото­рый пере­хо­дит весь про­све­щён­ный мир.

Посмот­ри­те, как устро­е­ны и как рабо­та­ют базы дан­ных: что такое запро­сы, чем SQL-базы отли­ча­ют­ся от осталь­ных, как заста­вить их рабо­тать быст­рее и так далее. С база­ми дан­ных при­дёт­ся рабо­тать чаще все­го.

Узнай­те, что такое API, для чего оно нуж­но и как одни сай­ты могут исполь­зо­вать воз­мож­но­сти дру­гих. Самый попу­ляр­ный при­мер — исполь­зо­ва­ние API-карт, что­бы пока­зы­вать посе­ти­те­лям место на кар­те и стро­ить марш­рут до заве­де­ния.


Почи­тай­те про сер­ве­ры — что за опе­ра­ци­он­ные систе­мы там рабо­та­ют, что уме­ют, поче­му имен­но сде­ла­но так, а не ина­че. Боль­ше все­го про это зна­ют сисад­ми­ны, мож­но спро­сить у них.

Прой­ти 20 бес­плат­ных часов в Прак­ти­ку­ме, само­му сде­лать один пол­но­цен­ный про­ект и понять, насколь­ко эта про­фес­сия вам инте­рес­на.

Да, мы обучаем бэкендов Пер­вые 20 часов бес­плат­но. Про­верь­те, под­хо­дит ли вам эта про­фес­сия, а потом кай­фуй­те на хоро­шей зар­пла­те. Про­ве­рить и кай­фа­нуть

Так что же все-таки выбрать

Опытные разработчики рекомендуют начинать с верстки, после чего изучать JavaScript и сопутствующие технологии. Часто уже на этом этапе начинается освоение PHP или Node.js, ведь для полноценной работы фронтенд-специалисту нужно знать основы бекенда. Если по ходу уроков человек понимает, что его больше увлекает backend, он в любой момент может начать углубляться в интересующую область.

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

Серия бесплатных видео-уроков от EasyCode

Перед изучением JavaScript идет верстка, которая считается способом «попробовать программирование», ведь обучение пользованию разметкой и стилями несложное и быстрое — отличный вариант для новичка.

Эксперимент 1

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

Используя CodePen, вы убиваете двух зайцев сразу. С одной стороны вы практикуете HTML и CSS. C другой стороны вы создаете основу для портфолио с иллюстрациями вашего прогресса. Мы так же будем использовать Dribbble, который полон вдохновляющего дизайна.

Идите на Dribbble и найдите дизайн, код для которого вы сможете написать за пару часов. Я выбрал несколько примеров, с которых вы можете начать: , , , и . Я выбирал дизайны, ориентированные в первую очередь на мобильную разработку, потому что они менее сложны, чем их аналоги для обычных экранов. Тем не менее вы вольны выбрать вариант для десктопов.

Когда вы определились с дизайном, идите и попробуйте сверстать его на CodePen. Если вы застряли, помните что StackOverflow (англ.) ваш друг. Другой полезной практикой будет пойти на такие сайты, как Medium, AirBnB и Dropbox и при помощи инструментов разработчика (англ.) посмотреть как реализована разметка и стили. Так же взгляните на некоторые примеры на CodePen. Я прикрепляю несколько хороших ссылок:

  • Меню приложения
  • Виджет Twitter
  • Простое плоское меню

Не стоит расстраиваться если ваша копия будет отличатся от оригинала. Продолжайте практиковаться с разными дизайнами и со временем вы заметите существенные улучшения.

Если у вас нет за плечами опыта в дизайне, вероятнее всего, ваш дизайнерский глазомер не настроен. Фронтенд-разработчик с хорошим дизайнерским чутьем будет в состоянии отличить хороший дизайн и сверстать его идеально. Я написал статью несколько недель назад о том, как развить свое дизайнерское чутье (рус.).

Аутентификация

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

Можно выделить два основных типа аутентификации:

  1. Запоминающая предыдущее состояние — реализуется с помощью сессий. Пользователь авторизуется один раз, а затем получает возможность свободно передвигаться по приложению и доступ к защищенным ресурсам (таким, как банковские транзакции или селфи в Snapchat), не отправляя данные, которые подтверждают его вход повторно.
  2. Не запоминающая предыдущее состояние — реализуется с помощью токенов. Пользователи делают все то же самое, но при выполнении каждого HTTP-запроса пользователю нужно отправлять идентификационные данные. Так обычно поступают с REST API. Сейчас золотой стандарт, не запоминающей состояние аутентификации с токенами, — JWT.

Есть и более продвинутый сценарий — многофакторная аутентификация. Она повышает безопасность приложения, добавляя дополнительные уровни защиты к логину и паролю. Хорошие примеры реализации есть у  и Amazon.

Прим. перев. А у нас есть разъясняющая статья про двухфакторную аутентификацию и протокол FIDO U2F.

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

Двигаемся к Модели приложения (Application model)

Вскоре стало понятно, что Application State не может быть полностью изолирован от GUI. Всегда существует какая-то логика представления (Presentation logic) или состояние представления (View state), которые необходимо поддерживать.

Но это может вызвать проблемы. Давайте возьмем наш предыдущий пример счетчика. Когда наш счетчик достигнет 10, мы должны изменить цвет метки с черного на красный, чтобы указать предупреждение. Такое поведение изменения цвета на самом деле не является бизнес-логикой или задачей. Это чисто эстетическая часть (UX), которая должна быть учтена. Настоящий вопрос — где? Это должна быть Модель или Представление?

Поскольку эта Логика представления или Состояние представления в основном представляет собой состояние, полученное из Модели предметной области, оно должно поддерживаться в Модели. Но Модель предметной области, поддерживающая визуальный аспект, — то есть красный цвет — по определению не очень хорошо. Если же мы поместим это в объект Представление, то это создаст еще один набор проблем. Наш виджет больше не является шаблонным. Мы не можем использовать его в другом месте. Кроме того, добавление условия с жестко закодированным числом 10 в наш объект View означает, что мы ограничиваем некоторую часть бизнес-логики.

Чтобы решить эту проблему, в исходную MVC была добавлена еще одна сущность — Модель приложения (Application Model, AM). Как видно на рисунке, с Моделью приложения пара View-Controller не имеет прямого доступа к модели. Вместо этого они регистрируются в событиях Модели приложения и используют его для доступа к необходимым данным.

Потоки данных остаются такими же, как и у классического MVC. Конечно, у каждой модели есть свои плюсы и минусы, и AM-MVC не исключение. Наиболее заметная проблема заключается в том, что Application Model не имеет прямой ссылки на объект View и, следовательно, не может манипулировать им напрямую, даже если Application Model предназначена для поддержания состояния View.

MVC предков — Первоисточник

Отделение данных от представления является основной темой графических пользовательских интерфейсов (как веб-ориентированных, так и настольных). С MVC — Model View Controller, отделение представления (View) от доменной области (Model) было основной мотивацией проектирования. И, без сомнения, MVC была плодотворной работой, которая повлияла на будущие поколения.

MVC был представлен для Smalltalk-80. В MVC объект View отображает данные, хранящиеся в объекте Model. Прежде чем мы сможем полностью изучить потоки данных в MVC, мы должны понять среды прикладных программ того времени (около 1970-х годов):

  • Этот MVC был предназначен только для настольных приложений. Веб еще не родился. Мы говорим о десятилетии до этого.
  • Забудьте о Web. Сложных операционных систем с графическим интерфейсом не существует.
  • Это означает, что прикладное программное обеспечение было очень близко «железу» систем.

Эти ограничения имели важные последствия для MVC. Обязанностью объекта Controller стало реагирование на пользовательские вводы, такие как клавиатура или мышь, и их преобразование в действия над моделью. Кроме того, отсутствие графических элементов в операционных системах означает, что Представление (View) не соответствует тому, что на экране.

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

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

С точки зрения связей:

  1. View и Controller содержат прямую ссылку на Model, но не наоборот. Это означает, что Model не зависит от пользовательского интерфейса и может меняться, не беспокоясь о проблемах пользовательского интерфейса.

  2. Модель реализует шаблон Observer, и на него подписывается один или несколько объектов View. Когда Model изменяется, она вызывает событие, и View обновляется после реакции на событие.

В MVC есть два разных потока данных. Во View-потоке Model не участвует. Это только изменение пользовательского интерфейса. Показ эффекта нажатия кнопки или реакция на событие прокрутки мыши — пример View-потока.

Сегодня мы больше не используем этот MVC и поэтому иногда его называют классическим MVC или MVC предков (father’s MVC).


С этим читают