Что такое веб-приложение простыми словами: виды и алгоритм разработки

Ещё 15–20 лет назад нельзя было предположить, что веб-приложения станут неотъемлемой частью жизни. Сегодня эта разновидность онлайн-инструментов используется для различных задач, включая оптимизацию бизнес-процессов, продажу товаров и услуг, распространение информации, общение пользователей друг с другом.

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

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

Эту разновидность инструментов нельзя путать с сайтами. Веб-приложения интерактивны, пользователи могут совершать в них различные действия: заказать товар или услугу, забронировать билет, оставить комментарий или отзыв, редактировать контент и так далее. Примерами веб-приложений могут быть в том числе полноценные онлайн-редакторы, какие как «Документы» от Google или система управления контентом сайта (CMS) «Tilda».

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

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

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

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

• статистические — серверная часть создаёт страницу в ответ на запрос и отправляет её в браузер вне зависимости от действий пользователя, так что разные пользователи увидят по одному и тому же запросу одинаковый материал;
• динамические — серверная часть формирует страницу в ответ на запрос, только материал предварительно проходит через сервер приложений и формируется в зависимости от того, какие команды были отправлены.

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

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

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

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

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

Здесь выделяют веб-приложения нескольких категорий:

• многостраничные (MPA) — запрос отправляется на сервер, а страница полностью обновляется в результате ответа, заменяется на новую;
• одностраничные (SPA) — после отправки запроса на сервер обновляется часть той страницы, из которой состоит приложение, без полной перезагрузки;
• прогрессивные (PWA) — сохраняют свою функциональность, даже когда работают в режиме офлайн из-за отключения доступа к интернету.

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

Современные веб-приложения могут выполнять множество разных функций. Например, это могут бытькорпоративные порталы, CRM (customer relationship management), ERP (enterprise resource planning), CMS (content management system), электронные коммерческие системыи так далее.

В этой категории выделяют несколько разновидностей:

• Абсолютно без компонентных моделей. Нередко простые скриптовые языки разработки помогают создать программу, которую условно относят к стилю CGI, хотя она является полноценным приложением.
• С универсальными компонентными моделями, которые не предназначены для одних лишь веб-приложений. Например, с помощью COM/ActiveX-объектов на платформе Windows удавалось расширить функциональность веб-сервера, реализовать ту или иную бизнес-логику.
• Со специализированными компонентными моделями. Примером являются сервлеты и документы — универсальные компоненты в мире разработки на языке Java. Управляет этими компонентами особый элемент — веб-контейнер.

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

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

• Сбор требований и разработка ТЗ. Заказчик озвучивает как основные задачи, так и более глобальные цели, а также дополняет это своими требованиями, чтобы была возможность ознакомить разработчиков с заданием.

• Прототипирование. Исполнитель создаёт прототип будущего проекта, где отражены будущие блоки и показано, как они будут взаимодействовать в web-среде. Важно выбрать надёжного и опытного исполнителя. Также на данном этапе определяются необходимые технологии разработки.

• Создание дизайна. Разработчики создают макет внешнего вида, чтобы согласовать его с заказчиком вслед за функциональным прототипом.

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

• Тестирование. Тестировщикам нужно убедиться, что веб-приложение полностью справляется со своими функциями.

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

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

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

• Безопасность. Минимальный доступ к серверным элементам и базам данных. А значит, меньше всего можно опасаться взлома и других негативных последствий.
• Доступ с разных устройств. Современные движки позволяют получать доступ к веб-приложению параллельно с разных платформ, например с компьютера или ноутбука на Windows, с мобильных устройств на Android и Apple.

• Отсутствие клиентского ПО. Не нужно расходовать лишние ресурсы — место и память на установку клиентского ПО на устройство.
• Масштабируемость — веб-приложение способно справляться с нужным объёмом задач в зависимости от их количества.

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

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

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

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

Ставьте лайк и подписывайтесь на наши обновления, впереди вас ждет еще много всего интересного)

Источник статьи: http://vc.ru/dev/397220-chto-takoe-veb-prilozhenie-prostymi-slovami-vidy-i-algoritm-razrabotki

Поиск ответа

Вопрос № 296685

Здравствуйте! Уточните, пожалуйста, нужнали запятая в этом объявлении? : Приглашаем к сотрудничеству владельцев Web- камер ? для трансляции в эфире нашего чата. Спасибо.

Ответ справочной службы русского языка

Добрый день, подскажите, пожалуйста, допустимо ли написание web- проект? Или все же правильно веб-проект? Спасибо.

Ответ справочной службы русского языка

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

Как правильно написать, web- страница или веб-страница? Спасибо

Ответ справочной службы русского языка

Ответ справочной службы русского языка

Пожалуйста, ответьте на вопрос:
Демо- Web- интерфейс — как правильно? Верно ли расставлены дефисы?
спасибо

Ответ справочной службы русского языка

Орфографически верно: демо-веб-интерфейс .

Здравствуйте! Подскажите, пожалуйста, можно ли писать web- сайт или обе части это слова должны быть написаны по-русски: веб-сайт? Спасибо!

Ответ справочной службы русского языка

Предпочтительно писать слово веб-сайт.

Здравствуйте! Я всегда задумывался над тем, как правильно писать: веб-сайт, вебсайт или web- сайт? Также возникают вопросы с такими словами как «вебмастер» и «веб-дизайнер», «веб-программист» (мне действительно кажется что первое пишется слитно, а второе и третье — через дефис). Допустимо ли употребление слова «веб» в значении «сеть, интернет»?

Ответ справочной службы русского языка

Правильное написание: веб-сайт (именно такое написание рекомендует «Русский орфографический словарь» РАН). В значении «Интернет» существительное Веб пишется с большой буквы. Слова с первой частью веб. ( веб-программист, веб-дизайнер, веб-мастер ) пишутся через дефис, со строчной буквы.

Здравствуйте! Скажите пожалуйста, правильно ли написание слова «интернет» в середине предложения с большой буквы, и склоняется ли это слово? «Размещение электронной версии каталога в Интернете на web- странице выставочной компании.»

Ответ справочной службы русского языка

Да, слово _Интернет_ пишется с большой буквы и склоняется. Вы написали верно.

Добрый день! У меня к Вам оргомная прсьба. Знакомые открывают новое направление и попросили написать для них коммерческое предложение, что я и сделала. Но я не уверена, что здесь нет орфографических ошибок. Пожалуйста, проверьте текст. С благодарностью приму все замечания и исправления. Уважаемые дамы и господа! Не для кого не секрет, что в последнее время все большей популярностью пользуется всемирная сеть Интернет. В связи с этим наша компания запускает новый проект — _______________ ___________________ – это информационно-справочный Интернет-сайт, посвященный развлечениям и досугу. Поскольку, наш город растет и развивается с неумолимой скоростью и почти каждый день открываются новые торговый центры, кафе, клубы и прочие заведения, мы считаем, что столица давно нуждается в таком проекте. На сайте будет размещаться информация рекламного характера, позволяющая жителям и гостям нашей столицы легко ориентироваться и выбирать для себя нужное из огромного количества предложений. Одним из неоспоримых преимуществ Интернет сайта является то, что Ваша информация работает на Вас 24 часа в сутки, 7 дней в неделю, при необходимости она обновляется. Наша цель – собрать информацию обо всех организациях, деятельность которых, так или иначе, соприкасается с досугом и развлечениями. Мы отлично понимаем, что у нас огромная целевая аудитория и для Вашего удобства мы сформировали 3 варианта размещения информации. Вы можете выбрать тот пакет, который оптимально подходит для Вас. У многих фирм существуют собственные web- сайты, но зачастую их посещаемость оставляет желать лучшего, ведь тратить огромные средства на продвижение в сети иногда бывает не целесообразно. _________________ – это идеальный вариант рекламы не только Вашей фирмы, но и Вашего персонального электронного представительства. Мы постоянно работаем над продвижением сайта и стремимся занять лидирующие позиции. Помимо прочего на сайте так же будут размещаться новостная лента, интересные фотографии о нашем городе, рубрика «Халява», в которой Вы можете размещать информацию о предстоящих мероприятиях, о скидках, распродажах, акциях и т.д. совершенно бесплатно, прогноз погоды, курсы валют и многое другое. P.S.: Поскольку наш проект пока только набирает обороты нам хочется знать Ваше мнение. Будем рады принять Ваши пожелания, предложения и замечания по e-mail.

Ответ справочной службы русского языка

«Справочное бюро» не занимается проверкой текстов.

Добрый день! Скажите, пожалуйста, нужна ли запятая после «однако» в следующем предложении: Однако когда запрашивается динамическая страница, действия web- сервера не столь однозначны. Спасибо.

Ответ справочной службы русского языка

Как правильно писать « Web- страницы»?

Ответ справочной службы русского языка

Здравствуйте, скажите пожалуйста, как следует писать Web- страница или web- страница? Спасибо, Ирина

Ответ справочной службы русского языка

В русском языке есть слово _веб-страница_.

Запятая ставится в обоих случаях или нигде? Спасибо. Каталоги самых известных поисковых машин содержат ссылки на более, чем миллионы web- ресурсов. Каталог содержит более, чем 150 наименований продукции.

Ответ справочной службы русского языка

Запятые не ставятся в обоих случаях.

Web- сайт[,] как эффективный инструмент pr-кампании.

Ответ справочной службы русского языка

Подскажите, пожалуйста, как правильно: «закончить дела по окончанИЮ рабочего дня» или «закончить дела по окончанИИ рабочего дня»? И еще одни вопрос: Во фразе «Если Вы разбираетесь в компьютерных технологих и знаете, чем отличается браузер от web- обозревателя Вы наш главный кандидат» правильно ли расставлены знаки препинания?

Ответ справочной службы русского языка

Правильно: _по окончании рабочего дня_.
Правильно: _Если Вы разбираетесь в компьютерных технологиях и знаете, чем отличается браузер от web- обозревателя, Вы наш главный кандидат_.

Источник статьи: http://new.gramota.ru/spravka/buro/search-answer?s=web-

Как разработать веб-приложение за 8 шагов

Если вы всерьез подумываете о разработке своего веб-приложения, сначала ответьте на два вопроса:

• Для решения какой задачи будет использоваться это приложение?
• Каким способом будет разработано данное приложение?

Первое — веб-приложение всегда разрабатывается для решения конкретной задачи, как правило, одной. Оно должно быстро реагировать на изменения, и чем проще и меньше время реакции, тем более веб-приложение жизнеспособно.

Второе — есть по меньшей мере 6 путей к разработке веб-приложения, самым современным из которых является реализация фронтенда как single page application, где контакт с бэкендом реализуется через REST API. Данный путь к созданию веб-приложения достигается за 8 шагов.

1. Работа с бизнес-логикой бэкенда

Есть два способа такой работы: вы можете сгруппировать бизнес-логику бэкенда в одном сервисе (монолитная логика) или реализовать каждый ее компонент в отдельном микросервисе. Работая с небольшим проектом, используйте первый способ, а при работе с крупным проектом идеально подойдет второй.

2. Выбор языка программирования

Если вам менее важна производительность веб-приложения, пишите на Python (фреймворки Django, Flask), Node JS (фреймворки Express JS, Koa JS, Gatsby JS), Ruby (фреймворки Ruby on Rails, Grape). Если в приоритете скорость приложения — используйте Golang (фреймворки Gingonic, Beego, Revel). Еще вы можете использовать популярный язык программирования от Microsoft — C#, который произносится как «си шарп». Он разработан в качестве языка прикладного уровня для CLR. С# вобрал в себя многое от C++, Модула, Delphi, Smalltalk и Java, но разница состоит в том, что С# исключает модели, которые зарекомендовали себя как проблемные при разработке ПС. К примеру, C# в отличие от C++ не поддерживает множественное наследование классов, но допускает множественную реализацию интерфейсов. Главное, какой бы язык вы не выбрали, кодить на том, который вы хорошо знаете.

3. Реализация бизнес-логики

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

Presenter обрабатывают события от пользовательского интерфейса (UI) и выполняют роль callback из внутренних уровней (Interactors). Presenters легко тестировать и их задача состоит в том, чтобы получить информацию от веб-приложения и преобразовать ее для перемещения presenters на экран с помощью представления (View).

Interactor по факту вмещают бизнес-логику веб-приложения, то есть проверку условий и обработку информации. Interactor работают фоном и перемещают события и информацию на верхний уровень, presenters, c помощью callback.

Тестирование нужно обязательно делать для того, чтобы знать, правильно ли работает бизнес-логика вашего веб-приложения, а также для того чтобы не проверять постоянно «вручную» работоспособность кода. Используйте автоматическое тестирование для модулей и библиотек, соответствия UI/UX и API. Пропишите несколько вариантов тестирования. Разработайте roadmap для платформы, чтобы управлять испытаниями для всех типов тестирования. Обязательно сделайте подключение инструментов отслеживания текущего покрытия кода, чтобы убедиться в том, что ваше веб-приложение не «виснет» и работает без багов и перебоев.

5. Добавление поддержки сваггера

Swagger – это «умная» документация RESTful web-API. По сути, это фреймворк для спецификации REST API, дающий возможность не только просматривать спецификацию в интерактивном режиме, но и отправлять запросы, именуемые Swagger UI. А теперь на счет веб-приложения.

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

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

6. Работа с бизнес-логикой фронтенда

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

7. QA-тестирование фронтенда

Фронтенд тестируют двумя основными видами тестов — на логику и на отображение. Тесты на логику проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы наполнение демонстрировалось пользователю в том виде, который вы задумали, прописывая фронтенд. Для осуществления QA-тестирования фронтенда используйте такие фреймворки, как Mocha, Chai, Jest, Ava, Enzyme, Jest — они самые ходовые, простые в эксплуатации и наиболее понятные из всех.

8. Мониторинг качества веб-приложения

Когда вы завершили седьмой этап, ваше веб-приложение, можно сказать, готово. Ну, или оно находится на финальной стадии готовности — 98%. Что вам нужно знать по итогу? Естественно, первое, что нужно, — это понять, насколько качественно реализовано приложение, как оно будет работать и на какое время хватит его износостойкости. В этом вам поможет Lighthouse — автоматизированный инструмент с открытым исходным кодом для мониторинга качества вашего веб-приложения. Lighthouse проводит системный аудит производительности и доступности веб-приложения для понимания обычного пользователя.

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

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

Источник статьи: http://vc.ru/dev/231077-kak-razrabotat-veb-prilozhenie-za-8-shagov

Делаем современное веб-приложение с нуля

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

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

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

Введение

Перед разработкой, конечно, сперва нужно определиться, что мы разрабатываем! В качестве модельного приложения для этой статьи я решил сделать примитивный wiki-движок. У нас будут карточки, оформленные в Markdown; их можно будет смотреть и (когда-нибудь в будущем) предлагать правки. Всё это мы оформим в виде одностраничного приложения с server-side rendering (что совершенно необходимо для индексации наших будущих терабайт контента).

Давайте чуть подробнее пройдёмся по компонентам, которые нам для этого понадобятся:

• Клиент. Сделаем одностраничное приложение (т.е. с переходами между страницами посредством AJAX) на весьма распространённой в мире фронтенда связке React+Redux.
• Фронтенд. Сделаем простенький сервер на Express, который будет рендерить наше React-приложение (запрашивая все необходимые данные в бэкенде асинхронно) и выдавать пользователю.
• Бэкенд. Повелитель бизнес-логики, наш бэкенд будет небольшим Flask-приложением. Данные (наши карточки) будем хранить в популярном документном хранилище MongoDB, а для очереди задач и, возможно, в будущем — кэширования будем использовать Redis.
• Воркер. Отдельный контейнер для тяжёлых задач у нас будет запускаться библиотечкой RQ.

Инфраструктура: git

Наверное, про это можно было и не говорить, но, конечно, мы будем вести разработку в git-репозитории.

(Здесь же стоит сразу наполнить .gitignore .)

Итоговый проект можно посмотреть на Github. Каждой секции статьи соответствует один коммит (я немало ребейзил, чтобы добиться этого!).

Инфраструктура: docker-compose

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

Добавим в репозиторий файл docker-compose.yml следующего содержания:

Давайте разберём вкратце, что тут происходит.

• Создаётся контейнер MongoDB и контейнер Redis.
• Создаётся контейнер нашего бэкенда (который мы опишем чуть ниже). В него передаётся переменная окружения APP_ENV=dev (мы будем смотреть на неё, чтобы понять, какие настройки Flask загружать), и открывается наружу его порт 40001 (через него в API будет ходить наш браузерный клиент).
• Создаётся контейнер нашего фронтенда. В него тоже прокидываются разнообразные переменные окружения, которые нам потом пригодятся, и открывается порт 40002. Это основной порт нашего веб-приложения: в браузере мы будем заходить на http://localhost:40002.
• Создаётся контейнер нашего воркера. Ему внешние порты не нужны, а нужен только доступ в MongoDB и Redis.

Теперь давайте создадим докерфайлы. Прямо сейчас на Хабре выходит серияпереводовпрекрасныхстатей про Docker — за всеми подробностями можно смело обращаться туда.

Подразумевается, что мы запускаем через gunicorn Flask-приложение, скрывающееся под именем app в модуле backend.server .

Не менее важный docker/backend/.dockerignore :

Воркер в целом аналогичен бэкенду, только вместо gunicorn у нас обычный запуск питонячьего модуля:

Мы сделаем всю работу в worker/__main__.py .

.dockerignore воркера полностью аналогичен .dockerignore бэкенда.

Наконец, фронтенд. Про него на Хабре есть целая отдельная статья, но, судя по развернутой дискуссии на StackOverflow и комментариям в духе «Ребят, уже 2018, нормального решения всё ещё нет?» там всё не так просто. Я остановился на таком варианте докерфайла.

• всё кешируется как ожидается (на нижнем слое — зависимости, на верхнем — билд нашего приложения);
• docker-compose exec frontend npm install —save newDependency отрабатывает как надо и модифицирует package.json в нашем репозитории (что было бы не так, если бы мы использовали COPY, как многие предлагают). Запускать просто npm install —save newDependency вне контейнера в любом случае было бы нежелательно, потому что некоторые зависимости нового пакета могут уже присутствовать и при этом быть собраны под другую платформу (под ту, которая внутри докера, а не под наш рабочий макбук, например), а ещё мы вообще не хотим требовать присутствия Node на разработческой машине. Один Docker, чтобы править ими всеми!

Ну и, конечно, docker/frontend/.dockerignore :

Итак, наш каркас из контейнеров готов и можно наполнять его содержимым!

Бэкенд: каркас на Flask

Добавим flask , flask-cors , gevent и gunicorn в requirements.txt и создадим в backend/server.py простенький Flask application.

Мы указали Flask подтягивать настройки из файла backend._settings , а значит, нам также потребуется создать (хотя бы пустой) файл backend/dev_settings.py , чтобы всё взлетело.

Теперь наш бэкенд мы можем официально ПОДНЯТЬ!

Фронтенд: каркас на Express

Начнём с создания пакета. Создав папку frontend и запустив в ней npm init , после нескольких бесхитростных вопросов мы получим готовый package.json в духе

В дальнейшем нам вообще не потребуется Node.js на машине разработчика (хотя мы могли и сейчас извернуться и запустить npm init через Docker, ну да ладно).

В Dockerfile мы упомянули npm run build и npm run start — нужно добавить в package.json соответствующие команды:

Команда build пока ничего не делает, но она нам ещё пригодится.

Добавим в зависимости Express и создадим в index.js простое приложение:

Теперь docker-compose up frontend поднимает наш фронтенд! Более того, на http://localhost:40002 уже должно красоваться классическое “Hello, world”.

Фронтенд: сборка с webpack и React-приложение

Пришло время изобразить в нашем приложении нечто больше, чем plain text. В этой секции мы добавим простейший React-компонент App и настроим сборку.

При программировании на React очень удобно использовать JSX — диалект JavaScript, расширенный синтаксическими конструкциями вида

Однако, JavaScript-движки не понимают его, поэтому обычно во фронтенд добавляется этап сборки. Специальные компиляторы JavaScript (ага-ага) превращают синтаксический сахар в уродливый классический JavaScript, обрабатывают импорты, минифицируют и так далее.

2014 год. apt-cache search java

Итак, простейший React-компонент выглядит очень просто.

Он просто выведет на экран наше приветствие более убедительным кеглем.

Добавим файл frontend/src/template.js , содержащий минимальный HTML-каркас нашего будущего приложения:

Добавим и клиентскую точку входа:

Для сборки всей этой красоты нам потребуются:

webpack — модный молодёжный сборщик для JS (хотя я уже три часа не читал статей по фронтенду, так что насчёт моды не уверен);
babel — компилятор для всевозможных примочек вроде JSX, а заодно поставщик полифиллов на все случаи IE.

Если предыдущая итерация фронтенда у вас всё ещё запущена, вам достаточно сделать

для установки новых зависимостей. Теперь настроим webpack:

Чтобы заработал babel, нужно сконфигурировать frontend/.babelrc :

Наконец, сделаем осмысленной нашу команду npm run build :

Теперь наш клиент вкупе с пачкой полифиллов и всеми своими зависимостями прогоняется через babel, компилируется и складывается в монолитный минифицированный файлик ../dist/client.js . Добавим возможность загрузить его как статический файл в наше Express-приложение, а в дефолтном роуте начнём возвращать наш HTML:

Успех! Теперь, если мы запустим docker-compose up —build frontend , мы увидим “Hello, world!” в новой, блестящей обёртке, а если у вас установлено расширение React Developer Tools (Chrome, Firefox) — то ещё и дерево React-компонент в инструментах разработчика:

Бэкенд: данные в MongoDB

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

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

(Если вы до сих пор не используете аннотации типов в Python, обязательно гляньте эти статьи!)

Теперь создадим реализацию интерфейса CardDAO , принимающую на вход объект Database из pymongo (да-да, время добавить pymongo в requirements.txt ):

Время прописать конфигурацию монги в настройки бэкенда. Мы незамысловато назвали наш контейнер с монгой mongo , так что MONGO_HOST = «mongo» :

Теперь надо создать MongoCardDAO и дать Flask-приложению к нему доступ. Хотя сейчас у нас очень простая иерархия объектов (настройки → клиент pymongo → база данных pymongo → MongoCardDAO ), давайте сразу создадим централизованный царь-компонент, делающий dependency injection (он пригодится нам снова, когда мы будем делать воркер и tools).

Время добавить новый роут в Flask-приложение и наслаждаться видом!

Перезапускаем командой docker-compose up —build backend :

Упс… ох, точно. Нам же нужно добавить контент! Заведём папку tools и сложим в неё скриптик, добавляющий одну тестовую карточку:

Команда docker-compose exec backend python -m tools.add_test_content наполнит нашу монгу контентом изнутри контейнера с бэкендом.

Успех! Теперь время поддержать это на фронтенде.

Фронтенд: Redux

Теперь мы хотим сделать роут /card/:id_or_slug , по которому будет открываться наше React-приложение, подгружать данные карточки из API и как-нибудь её нам показывать. И здесь начинается, пожалуй, самое сложное, ведь мы хотим, чтобы сервер сразу отдавал нам HTML с содержимым карточки, пригодным для индексации, но при этом чтобы приложение при навигации между карточками получало все данные в виде JSON из API, а страничка не перегружалась. И чтобы всё это — без копипасты!

Начнём с добавления Redux. Redux — JavaScript-библиотека для хранения состояния. Идея в том, чтобы вместо тысячи неявных состояний, изменяемых вашими компонентами при пользовательских действиях и других интересных событиях, иметь одно централизованное состояние, а любое изменение его производить через централизованный механизм действий. Так, если раньше для навигации мы сперва включали гифку загрузки, потом делали запрос через AJAX и, наконец, в success-коллбеке прописывали обновление нужных частей страницы, то в Redux-парадигме нам предлагается отправить действие “изменить контент на гифку с анимацией”, которое изменит глобальное состояние так, что одна из ваших компонент выкинет прежний контент и поставит анимацию, потом сделать запрос, а в его success-коллбеке отправить ещё одно действие, “изменить контент на подгруженный”. В общем, сейчас мы это сами увидим.

Начнём с установки новых зависимостей в наш контейнер.

Первое — собственно, Redux, второе — специальная библиотека для скрещивания React и Redux (written by mating experts), третье — очень нужная штука, необходимость который неплохо обоснована в её же README, и, наконец, четвёртое — библиотечка, необходимая для работы Redux DevTools Extension.

Начнём с бойлерплейтного Redux-кода: создания редьюсера, который ничего не делает, и инициализации состояния.

Наш клиент немного видоизменяется, морально готовясь к работе с Redux:

Теперь мы можем запустить docker-compose up —build frontend, чтобы убедиться, что ничего не сломалось, а в Redux DevTools появилось наше примитивное состояние:

Фронтенд: страница карточки

Прежде, чем сделать страницы с SSR, надо сделать страницы без SSR! Давайте наконец воспользуемся нашим гениальным API для доступа к карточкам и сверстаем страницу карточки на фронтенде.

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

Заведём компонент «карточка», принимающий в качестве props содержимое cardData (оно же — фактически содержимое нашей карточки в mongo):

Теперь заведём компонент для всей страницы с карточкой. Он будет ответственен за то, чтобы достать нужные данные из API и передать их в Card. А фетчинг данных мы сделаем React-Redux way.

Для начала создадим файлик frontend/src/redux/actions.js и создадим действие, которые достаёт из API содержимое карточки, если ещё не:

Действие fetchCard , которое, собственно, делает фетч, чуть-чуть посложнее:

Ох, у нас появилось действие, которое ЧТО-ТО ДЕЛАЕТ! Это надо поддержать в редьюсере:

(Обратите внимание на сверхмодный синтаксис для клонирования объекта с изменением отдельных полей.)

Теперь, когда вся логика унесена в Redux actions, сама компонента CardPage будет выглядеть сравнительно просто:

Добавим простенькую обработку page.type в наш корневой компонент App:

И теперь остался последний момент — надо как-то инициализировать page.type и page.cardSlug в зависимости от URL страницы.

Но в этой статье ещё много разделов, мы же не можем сделать качественное решение прямо сейчас. Давайте пока что сделаем это как-нибудь глупо. Вот прям совсем глупо. Например, регуляркой при инициализации приложения!

Теперь мы можем пересобрать фронтенд с помощью docker-compose up —build frontend , чтобы насладиться нашей карточкой helloworld …

Так, секундочку… а где же наш контент? Ох, да мы ведь забыли распарсить Markdown!

Воркер: RQ

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

Есть много опенсорсных реализаций очередей задач; мы возьмём Redis и простенькую библиотечку RQ (Redis Queue), которая передаёт параметры задач в формате pickle и сама организует нам спаунинг процессов для их обработки.

Время добавить редис в зависимости, настройки и вайринг!

Немного бойлерплейтного кода для воркера.

Для самого парсинга подключим библиотечку mistune и напишем простенькую функцию:

Логично: нам нужен CardDAO , чтобы получить исходники карточки и чтобы сохранить результат. Но объект, содержащий подключение к внешнему хранилищу, нельзя сериализовать через pickle — а значит, эту таску нельзя сразу взять и поставить в очередь RQ. По-хорошему нам нужно создать Wiring на стороне воркера и прокидывать его во все таски… Давайте сделаем это:

Мы объявили свой класс джобы, прокидывающий вайринг в качестве дополнительного kwargs-аргумента во все таски. (Обратите внимание, что он создаёт каждый раз НОВЫЙ вайринг, потому что некоторые клиенты нельзя создавать перед форком, который происходит внутри RQ перед началом обработки задачи.) Чтобы все наши таски не стали зависеть от вайринга — то есть от ВСЕХ наших объектов, — давайте сделаем декоратор, который будет доставать из вайринга только нужное:

Добавляем декоратор к нашей таске и радуемся жизни:

Радуемся жизни? Тьфу, я хотел сказать, запускаем воркер:

Ииии… он ничего не делает! Конечно, ведь мы не ставили ни одной таски!

Давайте перепишем нашу тулзу, которая создаёт тестовую карточку, чтобы она: а) не падала, если карточка уже создана (как в нашем случае); б) ставила таску на парсинг маркдауна.

Тулзу теперь можно запускать не только на backend, но и на worker. В принципе, сейчас нам нет разницы. Запускаем docker-compose exec worker python -m tools.add_test_content и в соседней вкладке терминала видим чудо — воркер ЧТО-ТО СДЕЛАЛ!

Пересобрав контейнер с бэкендом, мы наконец можем увидеть контент нашей карточки в браузере:

Фронтенд: навигация

Прежде, чем мы перейдём к SSR, нам нужно сделать всю нашу возню с React хоть сколько-то осмысленной и сделать наше single page application действительно single page. Давайте обновим нашу тулзу, чтобы создавалось две (НЕ ОДНА, А ДВЕ! МАМА, Я ТЕПЕРЬ БИГ ДАТА ДЕВЕЛОПЕР!) карточки, ссылающиеся друг на друга, и потом займёмся навигацией между ними.

Теперь мы можем ходить по ссылкам и созерцать, как каждый раз наше чудесное приложение перезагружается. Хватит это терпеть!

Сперва навесим свой обработчик на клики по ссылкам. Поскольку HTML со ссылками у нас приходит с бэкенда, а приложение у нас на React, потребуется небольшой React-специфический фокус.

Поскольку вся логика с подгрузкой карточки у нас в компоненте CardPage , в самом действии (изумительно!) не нужно предпринимать никаких действий:

Добавляем глупенький редьюсер под это дело:

Поскольку теперь состояние нашего приложения может изменяться, в CardPage нужно добавить метод componentDidUpdate , идентичный уже добавленному нами componentWillMount . Теперь после обновления свойств CardPage (например, свойства cardSlug при навигации) тоже будет запрашиваться контент карточки с бэкенда ( componentWillMount делал это только при инициализации компоненты).

Вжух, docker-compose up —build frontend и у нас рабочая навигация!

Внимательный читатель обратит внимание, что URL страницы не будет изменяться при навигации между карточками — даже на скриншоте мы видим Hello, world-карточку по адресу demo-карточки. Соответственно, навигация вперёд-назад тоже отвалилась. Давайте сразу добавим немного чёрной магии с history, чтобы починить это!

Самое простое, что можно сделать — добавить в действие navigate вызов history.pushState .

Теперь при переходах по ссылкам URL в адресной строке браузера будет реально меняться. Однако, кнопка «Назад» сломается!

Чтобы всё заработало, нам надо слушать событие popstate объекта window . Причём, если мы захотим при этом событии делать навигацию назад так же, как и вперёд (то есть через dispatch(navigate(. )) ), то придётся в функцию navigate добавить специальный флаг «не делай pushState » (иначе всё разломается ещё сильнее!). Кроме того, чтобы различать «наши» состояния, нам стоит воспользоваться способностью pushState сохранять метаданные. Тут много магии и дебага, поэтому перейдём сразу к коду! Вот как станет выглядеть App:

А вот как — действие navigate:

Вот теперь история заработает.

Ну и последний штрих: раз уж у нас теперь есть действие navigate , почему бы нам не отказаться от лишнего кода в клиенте, вычисляющего начальное состояние? Мы ведь можем просто вызвать navigate в текущий location:

Фронтенд: server-side rendering

Пришло время для нашей главной (на мой взгляд) фишечки — SEO-дружелюбия. Чтобы поисковики могли индексировать наш контент, полностью создаваемый динамически в React-компонентах, нам нужно уметь выдавать им результат рендеринга React, и ещё и научиться потом делать этот результат снова интерактивным.

Общая схема простая. Первое: в наш HTML-шаблон нам надо воткнуть HTML, сгенерированный нашим React-компонентом App . Этот HTML будут видеть поисковые движки (и браузеры с выключенным JS, хе-хе). Второе: в шаблон надо добавить тег

Источник статьи: http://habr.com/ru/post/444446/

Что такое веб-приложения, виды и их преимущества

Руководитель отдела веб-разработки

Время чтения: 10 минут

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

Что такое веб-приложение?

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

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

• социальные сети,
• игры,
• образовательные продукты,
• системы бронирования билетов и отелей,
• онлайн-магазины,
• финансовые решения,
• веб-версии ПО.

Виды веб-приложений

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

Есть три основных шаблона построения сайтов:

• MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие;
• SPA (single-page application): одностраничное приложение, содержащее HTML-страницу, которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки;
• PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.

Чтобы подробнее узнать про различия, преимущества и недостатки SPA, MPA и PWA, читайте нашу статью: “ Что такое SPA, MPA и PWA ”.

Другая классификация основана на предназначении веб-приложений. Вот самые популярные виды приложений для бизнеса:

• корпоративные порталы . Здесь вы можете автоматизировать многие бизнес-процессы с помощью одного продукта. Корпоративный портал позволяет работать с документами, отслеживать работу сотрудников, общаться с контрагентами, проводить PR-мероприятия, связывать подразделения компании и т. д.;
• CRM (customer relationship management) . Позволяет настроить воронку продаж, управлять взаимоотношениями с клиентами, содержать клиентскую базу и сократить документооборот;
• ERP (enterprise resource planning) . ERP-система может открыть вам новые возможности: стандартизировать формы отчетности, контролировать процессы, улучшить взаимодействие отделов и интегрировать контрагентов в рабочий процесс;
• системы электронной коммерции . Это ваша возможность детально рассказывать клиентам о продуктах, принимать заявки и, собственно, продавать товары или услуги. Так вы сократите путь товара к потребителю и снизите затраты на совершение сделки.

Принципы работы веб-приложений

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

В зависимости от типа веб-приложения принципы их работы могут отличаться:

• статические страницы . Пользователь делает запрос в браузере, а веб-сервер обрабатывает его и отправляет в ответ заранее созданную веб-страницу. Это может быть, например, новостной материал или другие данные, которые не зависят от действий пользователя;
• динамические страницы . Динамические страницы, напротив, не отправляются напрямую от веб-сервера браузеру. Сначала они направляются на сервер приложений, где считывается код и подбираются данные для формирования страницы. Только после этого страница отправляется на веб-сервер, а затем в браузер.

Преимущества веб-приложений

Экономия

В ходе разработки вам не придется создавать отдельные приложения для разных операционных систем — они работают одинаково в любых браузерах: Internet Explorer, Opera, Safari, Google Chrome и т.д.

Безопасность

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

Доступ с разных устройств

Пользователь может взаимодействовать с веб-приложением через компьютер, смартфон, планшет и т. д. Главное — доступ к интернету.

Отсутствие клиентского ПО

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

Масштабируемость

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

Как разработать веб-приложение

Для создания web приложений нужны разнообразные инструменты, которые помогут создать структуру, красиво оформить продукт и сделать его интерактивным. Вот основные технологии разработки веб-приложений :

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

• постановка целей и задач приложения . Клиент определяет, зачем и какой продукт ему нужен. Это включает не только основные функции, но и глобальные цели — продать, обучить и т.д.
• проработка технического задания . Команда разработки плотно общается с заказчиком, чтобы максимально точно определить требования к финальному продукту.
• прототипирование . Подрядчик создает прототип сайта и показывает клиенту примеры будущих веб-страниц. Важно подобрать хорошего исполнителя, который имеет достаточный опыт и разбирается в актуальных технологиях веб-разработки .
• создание макета дизайна веб-приложения . Дизайнеры работают над внешним видом продукта и согласовывают результат с заказчиком.
• разработка и верстка . Разработчик полностью создает веб-страницы, используя дизайн-макеты и техническое задание. Процесс делится на две части: backend и frontend. Backend-часть включает в себя внутренние процессы сайта, такие как синхронизация устройств или авторизация пользователей. Frontend-часть — это внешний вид продукта, то есть то, как кнопки реагируют на нажатие и как появляются всплывающие окна. После этого этапа приложение уже практически готово к использованию.
• наполнение контентом . Подрядчик делает финальную работу над приложением: добавляет нужный текст, картинки и видео на свои места.
• тестирование . Тестировщики проверяют, что приложение работает корректно и все объекты отображаются нужным образом.

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

Каким бы бизнесом вы ни занимались, веб-приложение может стать катализатором его развития и позволит вам построить систему взаимодействия пользователя и системы. Мы беремся за разработку приложений на заказ , учитывая особенности вашего бизнеса и целевой аудитории. Мы создаём продукты, которые помогают оптимизировать производственные процессы, эффективно продвигают бизнес наших клиентов и нравятся пользователям. Напишите нам на info@azoft.com , чтобы получить бесплатную оценку проекта и начать разработку web приложения .

Подпишитесь

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

Источник статьи: http://www.azoft.ru/blog/web-apps/

Как работают веб-приложения

1. Чем веб-приложения отличаются от сайтов

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

Сайты содержат различную статику, которая как и HTML-файл не генерируется на лету. Чаще всего это картинки, CSS-файлы, JS-скрипты, но могут быть и любые другие файлы: mp3, mov, csv, pdf.

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

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

2. Какие бывают веб-приложения

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

1. Backend (бэкенд или серверная часть приложения) работает на удаленном компьютере, который может находиться где угодно. Она может быть написана на разных языках программирования: PHP, Python, Ruby, C# и других. Если создавать приложение используя только серверную часть, то в результате любых переходов между разделами, отправок форм, обновления данных, сервером будет генерироваться новый HTML-файл и страница в браузере будет перезагружаться.
2. Frontend (фронтенд или клиентская часть приложения) выполняется в браузере пользователя. Эта часть написана на языке программирования Javascript. Приложение может состоять только из клиентской части, если не требуется хранить данные пользователя дольше одной сессии. Это могут быть, например, фоторедакторы или простые игрушки.
3. Single page application (SPA или одностраничное приложение). Более интересный вариант, когда используются и бэкенд и фронтенд. С помощью их взаимодействия можно создать приложение, которое будет работать совсем без перезагрузок страницы в браузере. Или в упрощенном варианте, когда переходы между разделами вызывают перезагрузки, но любые действия в разделе обходятся без них.

3. Pyhon-фреймворк Django aka бэкенд

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

Первым этапом запрос от пользователя попадает в роутер (URL dispatcher), который решает какую функцию для обработки запроса надо вызвать. Решение принимается на основе списка правил, состоящих из регулярного выражения и названия функции: если такой-то урл, то вот такая функция.

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

Данные приложения хранятся в базе данных (БД). Чаще всего используются реляционные БД. Это когда есть таблицы с заранее заданными колонками и эти таблицы связаны между собой через одну из колонок.

Данные в БД можно создавать, читать, изменять и удалять. Иногда для обозначения этих действий можно встретить аббревиатуру CRUD (Create Read Update Delete). Для запроса к данным в БД используется специальный язык SQL (structured query language).

В Джанго для работы с БД используются модели (model). Они позволяют описывать таблицы и делать запросы на привычном разработчику питоне, что гораздо удобнее. За это удобство приходится платить: такие запросы медленнее и ограничены в возможностях по сравнению с использованием чистого SQL.

Полученные из БД данные подготавливаются во вью к отправке на фронт. Они могут быть подставлены в шаблон (template) и отправлены в виде HTML-файла. Но в случае одностраничного приложения это происходит всего один раз, когда генерируется HTML-страница, на который подключаются все JS-скрипты. В остальных случаях данные сериализуются и отправляются в JSON-формате.

4. Javascript-фреймворки aka фронтенд

Клиентская часть приложения — это скрипты, написанные на языке программирования Javascript (JS) и исполняемые в браузере пользователя. Раньше вся клиентская логика основывалась на использовании библиотеки JQuery, которая позволяет работать с DOM, анимацией на странице и делать AJAX запросы.

DOM (document object model) — это структура HTML-страницы. Работа с DOM — это поиск, добавление, изменение, перемещеие и удаление HTML-тегов.

AJAX (asynchronous javascript and XML) — это общее название для технологий, которые позволяют делать асинхронные (без перезагрузки страницы) запросы к серверу и обмениваться данными. Так как клиентская и серверная части веб-приложения написаны на разных языках программирования, то для обмена информацией необходимо преобразовывать структуры данных (например, списки и словари), в которых она хранится, в JSON-формат.

JSON (JavaScript Object Notation) — это универсальный формат для обмена данными между клиентом и сервером. Он представляет собой простую строку, которая может быть использована в любом языке программирования.

Сериализация — это преобразование списка или словаря в JSON-строку. Для примера:

Десериализация — это обратное преобразование строки в список или словарь.

С помощью манипуляций с DOM можно полностью управлять содержимым страниц. С помощью AJAX можно обмениваться данными между клиентом и сервером. С этими технологиями уже можно создать SPA. Но при создании сложного приложения код фронтенда, основанного на JQuery, быстро становится запутанным и трудно поддерживаемым.

К счастью, на смену JQuery пришли Javascript-фреймворки: Backbone Marionette, Angular, React, Vue и другие. У них разная философия и синтаксис, но все они позволяют с гораздо большим удобством управлять данными на фронтенде, имеют шаблонизаторы и инструменты для создания навигации между страницами.

HTML-шаблон — это «умная» HTML-страница, в которой вместо конкретных значений используются переменные и доступны различные операторы: if, цикл for и другие. Процесс получения HTML-страницы из шаблона, когда подставляются переменные и применяются операторы, называется рендерингом шаблона.

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

5. Как клиент и сервер общаются между собой

Общение клиента с сервером происходит по протоколу HTTP. Основа этого протокола — это запрос от клиента к серверу и ответ сервера клиенту.

Для запросов обычно используют методы GET, если мы хотим получить данные, и POST, если мы хотим изменить данные. Еще в запросе указывается Host (домен сайта), тело запроса (если это POST-запрос) и много дополнительной технической информации.

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

Есть еще один запрос, который делается перед HTTP. Это DNS (domain name system) запроc. Он нужен для получения ip-адреса, к которому привязан запрашиваемый домен. Эта информация сохраняется в браузере и мы больше не тратим на это время.

Когда запрос от браузера доходит до сервера, он не сразу попадает в Джанго. Сначала его обрабатывает веб-сервер Nginx. Если запрашивается статический файл (например, картинка), то сам Nginx его отправляет в ответ клиенту. Если запрос не к статике, то Nginx должен проксировать (передать) его в Джанго.

К сожалению, он этого не умеет. Поэтому используется еще одна программа-прослойка — сервер приложений. Например для приложений на питоне, это могут быть uWSGI или Gunicorn. И вот уже они передают запрос в Джанго.

После того как Джанго обработал запрос, он возвращает ответ c HTML-страницей или данными, и код ответа. Если все хорошо, то код ответа — 200; если страница не найдена, то — 404; если произошла ошибка и сервер не смог обработать запрос, то — 500. Это самые часто встречающиеся коды.

6. Кэширование в веб-приложениях

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

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

• В Джанго пришел запрос на получение данных для графика в отчете. Мы достаем из БД данные, подготавливаем их и кладем в БД с быстрым доступом, например, memcached на 1 час. При следующем запросе мы сразу достанем их из memcached и отправим на фронтенд. Если мы узнаём, что данные перестали быть актуальными, мы их инвалидируем (удаляем из кэша).
• Для кэширования статических файлов используются CDN (content delivery network) провайдеры. Это серверы, расположенные по всему миру и оптимизированные для раздачи статики. Иногда бывает эффективнее положить картинки, видео, JS-скрипты на CDN вместо своего сервера.
• Во всех браузерах по умолчанию включено кэширование статических файлов. Благодаря этому, открывая сайт не в первый раз, все загружается заметно быстрее. Минус для разработчика в том, что со включенным кэшем не всегда сразу видны изменения сделанные в коде.

Источник статьи: http://habr.com/ru/post/450282/

Значение слова «веб-приложение»

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

веб-приложе́ние

1. информ. программа, запускаемая через браузер

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я стал чуточку лучше понимать мир эмоций.

Вопрос: горбатый — это что-то нейтральное, положительное или отрицательное?

Синонимы к слову «веб-приложение&raquo

Предложения со словом «веб-приложение&raquo

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

Понятия, связанные со словом «веб-приложение»

Отправить комментарий

Дополнительно

Предложения со словом «веб-приложение&raquo

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

Появление классификации угроз безопасности веб-приложений является исключительно важным событием в мире IT.

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

Синонимы к слову «веб-приложение&raquo

Правописание

Карта слов и выражений русского языка

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

Справочная информация по склонению имён существительных и прилагательных, спряжению глаголов, а также морфемному строению слов.

Сайт оснащён мощной системой поиска с поддержкой русской морфологии.

Источник статьи: http://kartaslov.ru/%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0/%D0%B2%D0%B5%D0%B1-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

Как разработать хорошее веб-приложение и избежать ошибок — отвечают эксперты

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

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

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

В своей работе мы используем платформу собственной разработки BuroData Platform и следующий технологический стек:

1. PHP позволяет нам в кратчайшие сроки разворачивать RESTful API и интегрироваться с API клиентов и других сервисов. Для написания сложных вычислений и выполнения высоконагруженных участков проекта используем компилируемый язык Go. Это позволяет гарантировать высокую устойчивость разрабатываемых систем.
2. В качестве JS-библиотеки для разработки пользовательских интерфейсов используем React. Использование React позволяет в кратчайшие сроки вносить изменения, которые появляются в дизайн-системе проекта.
3. Как основную базу данных используем PostgreSQL. Помимо высоких нагрузок, для которых данная БД используется, она позволяет хранить как структурированные объекты (стандартная реляционная БД), так и неструктурированные объекты в форматах JSON и JSONB, а также искать по ним, что позволяет более гибко подходить к выстраиванию архитектуры проектов.
4. Для высоконагруженных систем используем Redis: это позволяет избежать сбоев от высоких нагрузок и вычислений при синхронизации между компонентами разрабатываемой нами системы и при интеграции со сторонними сервисами.
5. В работе над проектами придерживаемся философии DevOps и принципа «инфраструктура как код» (IaC), что позволяет быть уверенным в стабильности поставляемого нами ПО.

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

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

Не советую бездумно гнаться за всем «модным и молодёжным»: не можете объяснить, зачем вам GraphQL и какие у него преимущества перед простым REST API из трёх запросов, — не используйте. Кажется, это очевидно, но я сам не раз попадал в эту ловушку. Подход «открыть awesome-лист и поставить всё» тоже не лучшее решение: наличие огромного количества сторонних зависимостей не делает проект круче.

Вопрос «какой фреймворк/ОРМ/админку использовать» решается просто: выбирайте тот инструмент, который лучше всего знаете. Ничего не знаете и не умеете — берите то, с чем быстрее и проще разобраться, где меньше всего «уличной магии». Например, из списка Yii/Laravel/Symfony я выберу Laravel. Из админок выберу AdminLTE, потому что она «ну вроде норм и работает». Ни один из авторов этих проектов до сих пор не заплатил мне за рекламу.

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

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

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

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

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

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

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

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

Однако самой, наверное, неожиданной рекомендацией будет избегать любых сторонних библиотек и фреймворков всегда, когда это возможно. Это относится как к клиентской части приложения, так и к серверной. Приложение должно быть максимально компактным и потреблять минимальное количество ресурсов. Например, использование очень популярной библиотеки jQuery (или ей подобных) значительно замедляет работу клиентской части и требует немало ресурсов, что совершенно не обязательно. Абсолютно всё, что нужно, можно написать просто на JavaScript, а более быстрая загрузка и работа клиентской части будет высоко оценена заказчиком.

То же относится и к серверной части, а особенно к построению API для взаимодействия между ними. Для этой цели вполне достаточно использования устоявшихся протоколов CGI или WebSocket там, где это нужно. Различные фреймворки типа ORM несколько облегчают работу программиста ценой снижения эффективности приложения, да ещё и добавляют зависимость от этих библиотек и привносят в систему все их недоработки.

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

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

Источник статьи: http://tproger.ru/experts/how-to-make-good-web-app/

Как создать веб-приложение: основные этапы

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

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

Зачем нужны веб-приложения

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

Веб-приложения могут пригодиться, чтобы:

• Оказывать услуги пользователю в режиме онлайн: продавать товар, записывать на мероприятие, проводить курсы и вебинары.
• Решать внутренние задачи компании. Большим организациям веб-приложение может понадобиться, чтобы координировать сотрудников, выстраивать внутреннюю логистику. Например, с помощью веб-приложений можно проводить онбординг новых сотрудников и налаживать рабочие процессы с подрядчиками.

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

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

Виды веб-приложений

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

Прежде всего, приложения можно разделить на кастомные (написанные кодом) и ноукод (собранные в конструкторах). Современные ноукод-редакторы, скажем, Webflow или Bubble позволяют создавать интерактивные решения — к ним можно подключить платежную систему и сделать работающий интернет-магазин. Ноукод выбирают, потому что это быстро и дешево. Но такие решения подходят разве что для MVP или простых задач — например, лендингов или джоб-бордов с информацией о вакансиях и контактами рекрутёра. Функциональность получается очень ограниченной, потому что ноукод-инструменты — это конструктор с фиксированным набором элементов. Производительность таких приложений тоже ниже, чем у кастомных — большой трафик они не выдержат. Поэтому если вам нужен полноценный сервис, с прицелом на большую аудиторию, стоит остановиться на кастомных решениях.

Хотите больше узнать о специфике ноукод-решений и их отличия от классической разработки? Можете прочитать нашу статью: мы подробно разобрали специфику работы с конструкторами.

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

Single Page Application — это одностраничное приложение. Для разработки таких приложений используют HTML и JavaScript. По сути, это разработка лендинга , только интерактивного. Но SPA могут быть достаточно сложными. Суть одностраничных приложений в том, что на сервере хранится одна HTML-страница, контент на которой обновляется по мере прокрутки или переходов по ссылкам. То есть когда вы нажимаете на кнопку, вы не переходите на новую страницу — элементы добавляются к уже загруженной. Например, по этому принципу работает Gmail.

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

• Настройка SEO-оптимизации для SPA будет более трудоемкой, чем для других вариантов.
• Трудно гарантировать безопасность таких страниц: они больше подвержены взломам и утечкам, чем MPA и PWA, которые мы рассмотрим ниже.

Multi Page Application — это многостраничные приложения. Они позволяют пользователю не просто скроллить окно браузера, а переходить между отдельными страницами. И загрузка контента в таких приложениях происходит целыми страницами. Это значит, например, что если пользователь совершил оплату, в SPA подгрузится окошко с подтверждением, а в MPA страница оплаты полностью обновится. Пример многостраничного приложения — интернет-магазин Amazon.

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

• Сложная и более дорогостоящая разработка и дизайн, чем для SPA.

Progressive Web Application — прогрессивные веб-приложения. Это что-то среднее между разработкой мобильного приложения и вебсайта. PWA можно сразу из браузера установить на главный экран смартфона в обход магазинов приложений. А ещё такие приложения работают офлайн и отправляют push-уведомления, но при этом открываются в браузере. Это возможно благодаря технологии Service Worker — скрипту, через который проходят все взаимодействия между фронтэндом и бэкендом. У этого скрипта есть доступ к кэшу и данным. По сути к большинству сайтов можно дописать Service Worker — и получится PWA. Поэтому часто на эту технологию переходят СМИ — например, The Washington Post.

• Сочетание офлайн- и онлайн- режима удобно для пользователя.
• Такие приложения можно сравнительно быстро разработать.

• Приложение может работать с перебоями в старых версиях браузера.
• Есть браузеры, которые вообще не поддерживают подобные приложения — например, Firefox.

SPA	MPA	PWA
Плюсы	— Экономия времени и бюджета — Приложение быстро работает — Легко сделать однообразный дизайн	— Простая SEO-оптимизация — Привычная структура с переходом между страницами	— Сочетание офлайн- и онлайн- режима — Доступно с мобильных устройств
Минусы	— Сложная SEO-оптимизация — Высокий риск взлома и утечки данных	— Сложная и более дорогостоящая разработка и дизайн, чем для SPA	— Работает с перебоями в старых версиях браузера, не работает в Firefox

Мы работаем на платформе Node.js для разработки бэкенда и React — для фронтенда.

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

Кто занимается разработкой

Нанимать свою команду для разработки приложения — долго и дорого. По данным Indeed.com https://www.indeed.com/hire/c/info/cost-of-hiring-employees?hl=en&co=US

, расходы на найм одного сотрудника начинаются от $4000 без учёта зарплат. Чтобы сэкономить, можно обратиться за веб-приложениями к фрилансерам. Но зачастую это не лучшее решение. Для полноценного приложения нужна команда из аналитиков, дизайнеров и программистов, и вряд ли один человек будет обладать всеми знаниями сразу. А если вы нанимаете нескольких фрилансеров, вам придётся брать на себя работу менеджера проектов. Так что самый простой способ разработать сайт для компании — обратиться в студию, где над проектом будет работать опытная и слаженная команда.

В процессе создания веб-приложения участвуют:

• Аналитики — они помогают лучше изучить нишу, определить целевую аудиторию и понять, какая функциональность необходима для успеха на рынке.
• UX/UI-дизайнеры. Продумывают пользовательский путь и создают прототипы. Потом отрисовывают непосредственно дизайн сайта : кнопки, иконки и другие элементы интерфейса.
• Фронтенд-разработчики. Превращают дизайн сайта (макет) в работающий сайт: оживляют кнопки и блоки с помощью кода.
• Бэкенд-разработчики. Отвечают за функциональность: подключают базы данных, платежные системы, выстраивают внутреннюю логику приложения.
• Тестировщики. Проверяют приложение на баги и помогают выпустить на рынок продукт, который работает без ошибок.

Этапы разработки

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

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

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

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

Результат: Готовая схема приложения, в которой показаны блоки интерфейса и взаимосвязи между ними. По прототипу вы сможете оценить функциональность приложения и его доступность.

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

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

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

Результат: дизайн становится интерактивным: можно нажимать кнопки, переходить по ссылкам. Но свои функции приложение ещё не выполняет.

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

Результат: полностью работающее приложение.

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

Результат: приложение работает без ошибок, риск их появления сведён к минимуму.

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

Стоимость разработки

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

☝Разумеется, мы приводим только приблизительные цифры: итоговая цена приложения зависит от множества нюансов. Если нужно будет больше или, наоборот, меньше функций, то и стоимость изменится. Обычно финальную сумму можно назвать, когда готов дизайн: тогда уже точно понятно, как будет выглядеть приложение и что в нем будет.

Социальная сеть, в которой реализованы:

• чат;
• лента новостей с комментариями;
• публичные страницы или форумы;
• профиль пользователя.

Это приложение будет стоить у нас около 10 182 000 рублей.

Сервис-агрегатор для путешественников: с бронированием отелей, ж/д или авиабилетов. В нем должны быть:

• личный кабинет;
• поиск с фильтрами;
• блог с рекомендациями по турам;
• оплата
• рассылка.

Такое веб-приложение будет стоить примерно 7 845 000 рублей.

Вот подробная таблица, в которой расписаны все этапы разработки с количеством часов и стоимостью:

Вид работы	Стоимость для соцсети	Стоимость для агрегатора
Аналитика	120 часов / 300.000 р.	120 часов / 300.000 р.
UX-дизайн	260 часов / 910.000 р.	150 часов / 525.000 р.
UI-дизайн
Фронтенд	1600 часов / 5.600.000 р.	1200 часов / 4.200.000 р.
Бэкенд	800 часов / 2.800.000 р.	600 часов / 2.100.000
Тестирование	540 часов / 972.000 р.	400 часов / 720.000 р.

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

Есть бизнес-идея? Обращайтесь к нам за консультацией!

Источник статьи: http://www.purrweb.com/ru/blog/kak-sozdat-veb-prilozhenie/

Урок 1. Web-приложение: понятие, компоненты и принципы работы

1. Сущность web-приложения
2. Пятиуровневая структура сети
3. Сетевые сервисы
4. История развития web-приложений
5. Типы web-приложений
6. Принцип работы web-приложений
7. HTTP-протокол

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

Мобильные приложения заточены исключительно для смартфонов и планшетов с учетом установленной там системы ( Android , iOS и др.). Это также добавляет боли разработчикам софта. Важно отметить, что многие мобильные приложения фактически являются web-приложениями (о чем подозревают не все пользователи), так как возможности «движков» браузеров это позволяют.

Наиболее динамично на сегодня развиваются web-приложения, так как они для своей работы требуют только установленный браузер на клиентской стороне. Они:

1. Могут работать как на смартфоне, так и персональном компьютере,
2. Практически независимы от железа
3. По функционалу скоро перестанут уступать десктопным аналогам.

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

Рассмотрим наиболее простую модель сетевых слоев, состоящую из пяти уровней. В литературе ее еще называют моделью TCP/IP .

1. Физический уровень

2. Канальный уровень

Канальный уровень отвечает за соединение устройств одной сети (локальной). Здесь используется два популярных протокола:

1. Ethernet (когда компьютеры соединяются кабелем)
2. WiFi (беспроводное соединение).

Чтобы разные устройства могли различаться, они имеют MAC-адреса , которые представляют собой уникальные идентификаторы. В мире практически нет двух гаджетов с одинаковыми MAC-адресами . Пример MAC-адреса : 12:FA:A9:11:BC:DE (шесть 16-ричных однобайтных чисел, разделенных двоеточием).

3. Сетевой уровень

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

На основании адресов устройств сети мы можем подключаться к сайтам, серверам, почтовым клиентам и получать требуемую информацию. Существует 2 протокола IP : 4-ой и 6-ой версий. В ближайшем будущем произойдет полный переход на последнюю версию, так как версия IPv4 уже не справляется с растущим количеством компьютеров и гаджетов с доступом к сети (более того, в 2020 году в мире закончились свободные IP-адреса ).

4. Транспортный уровень

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

Чтобы трафики не смешивались, каждая программа использует для сетевого общения определенный порт. Например, браузер для открытия сайта использует порт 80 , а для соединения с базой данных может открываться порт 8080 .

Наиболее популярны на транспортном уровне 2 протокола: TCP и UDP .

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

5. Уровень приложений

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

Здесь используется огромное количество разнообразных протоколов, среди которых:

1. HTTP (применяется браузером для получения данных с Интернета),
2. SMTP (для почтовых сервисов),
3. FTP (загрузка файлов),
4. BitTorrent (пиринговый протокол),
5. SSH (защищенное соединение).

Наиболее значимым в рамках курса является HTTP протокол, о котором пойдет речь ниже.

1 – DNS (Domain Name System, система доменных имен)

Любой сайт в сети имеет определенный адрес. Так, когда в браузере вы набираете строку google.com , то попадаете на вполне конкретный сайт. Однако как мы выяснили ранее, IP-адреса – это числа, и никаких человекоудобных форм представления у них нет. Так, главная страница Гугл на самом деле имеет адрес 173.194.222.101 .

Так каким же образом веб-браузер понимает написанные нами буквы google.com ? За это стоит благодарить DNS-сервера . Они хранят все имена сайтов и соответствующие им IP-адреса .

Браузеру все равно, что вы введете в адресную строку: набор чисел или имя сайта. На заре Интернета, когда было не так много сайтов, запомнить адреса 2-5 страниц было реальным. В любом случае, числа плохо укладываются в памяти, а вот слова – очень даже просто. Благодаря DNS нам не нужно помнить сочетания цифр.
К слову, узнать IP-адрес любого сайта можно в командной строке. Для Windows и UNIX-систем команда выглядит одинаково.

2 – NAT (Network Address Translation, преобразование сетевых адресов)

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

Когда вы запрашиваете адрес какой-то страницы в Интернете, то передаете, в том числе, свой адрес. Как же защититься? Разработчики сервиса NAT это предусмотрели. На самом деле запрос к удаленному серверу идет не от имени вашего ПК. Ваш реальный адрес маскируется роутером или файрволом и передается в скрытом виде. Особенно это удобно для крупных компаний, где компьютеры объединены в сеть (запрос будет отправляться не от отдельного ПК, а от общего роутера, поэтому узнать адрес конкретной машины практически невозможно).

3 – DHCP (Dynamic Host Configuration Protocol, протокол динамической настройки узла)

Любой компьютер в сети обязан иметь уникальный IP-адрес . В разных сетях адреса могут пересекаться, но в локальной или корпоративной – никак.

Представим ситуацию, когда у предприятия имеется 100-200 ПК, которые имеют выход в сеть. Перед администратором сети стоит непосильная задача: настроить каждую машину, постоянно следить за тем, чтобы не было повторяющихся адресов, так как начнется коллизия данных.

Компания Microsoft разработала технологию DHCP , которая позволяет динамически присваивать IP-адрес из диапазона доступных. Задача существенно упрощается: администратору требуется лишь один раз задать диапазон значений, а они сами будут подставляться по мере обращения компьютера к сети.

К слову, даже ваш ПК не имеет постоянного IP-адреса , если он не является статическим. Другими словами, если вы не задавали вручную IP-адрес , то ПК получает динамический адрес от DHCP-сервера . При перезагрузке роутера он может меняться.

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

Развитие веб-приложений напрямую связано с популяризацией Интернета. По мере появления новых технологий и инструментов совершенствовались и набирали популярность web-приложения.

Следует отметить, что первые web app появились до того, как Интернет стал массовым. Еще в 1987 году Ларри Уолл разработал Perl , серверный язык сценариев.

Самый первый сайт появился в 1991 году благодаря Тиму Бернерсу-Ли, который представил новую технологию World Wide Web , основанную на протоколе HTTP . Этот сайт существует до сих пор и каждый может с ним ознакомиться (http://info.cern.ch/WWW/TheProject).

Он представляет собой набор гипертекста со ссылками на основные понятия, направления развития ресурса и т.п. В сравнении с современными сетевыми проектами он выглядит просто и неказисто, но имеет историческое значение.

Долгое время web-приложения оставались простыми, так как не было инструментария и потребностей в их усложнении. Лишь только в начале 21 века они стали набирать популярность и к сегодняшнему моменту представлены огромным разнообразием.

Благодаря HTML (языку гипертекстовой разметки), CSS (каскадным таблицам стилей), Javascript (для оживления статики страниц), серверным технологиям ( Apache , Nginx , AJAX ) и языкам программирования ( Python , Java , PHP и др.) стало возможным делать крупные массовые web-приложения, обладающие большим функционалом.

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

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

Для работы веб-приложений требуется клиентская часть ( frontend ), т.е. интерфейс, представление на экране пользователя, и серверная часть (для обработки запросов, записи в базы данных получаемых сведений).

Хоть первые web-приложения и появились в конце 20 века, до сих пор нет единой классификации их видов. Это связано с тем, что последние 5-10 лет их развитие совершило революционный скачок, породив новые разновидности.

В общем виде все web-приложения можно разбить на 5 типов. Деление в некоторой степени условное, так как возможно сочетание нескольких типов в одном приложении.

1. Серверные web-приложения

Серверные web-приложения работают на удаленных компьютерах. Для их написания используют такие языки программирования: Python , Java , Ruby , PHP , C# и др. Они практически не требуют пользовательского вмешательства. Переход между страницами вызывает генерацию нового контента, который отображается у клиента.

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

2. Клиентские web-приложения

Клиентские приложения в чистом виде не требуют серверной части и обходятся возможностями JavaScript, используя в качестве оболочки браузер пользователя. Они не сохраняют результат своей работы дольше одной сессии.

Типичные примеры таких приложений: простые игры, браузерный фоторедактор.

3. SPA приложения

Single page application ( SPA , одностраничные веб-приложения) реализуют сложный функционал в рамках одного окна браузера без перезагрузки. Динамическое обновление содержимого страницы достигается технологией AJAX ( Asynchronous JavaScript and XML , асинхронный JavaScript и XML ). В ответ на действия пользователя (прокрутка страницы, нажатие кнопок, заполнение формы, движение ползунка и т.п.) содержание страницы будет меняться.

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

В сочетании с фреймворками JavaScript ( Angular , React , Vue ) работа таких программ становится максимально плавной.

Практически все почтовые сервисы являются SPA .

4. MPA приложения

Multi Page Application ( MPA , многостраничные web-приложения) применяются для построения сложных систем. В данном случае любые изменения в данных приводят к полной перезагрузке страницы. Когда имеется большой массив данных и контента, разнообразие представляемых сведений, MPA подходят лучше всего.

Несмотря на то, что они требуют больших объемов ресурсов для реализации и существенно дороже, другие виды web-приложений их заменить не могут. Однако тенденции показывают, что общая доля MPA постепенно снижается.
Стандартный пример такого приложения – интернет магазины с большим массивом товаров ( Amazon , Citilink и т.п.).

5. PWA приложения

Progressive Web Application ( PWA , прогрессивные web-приложения) – новый способ «подачи» web-сервисов, который максимально сближает их с обычным, привычным десктопным приложением, но на качественно более высоком уровне.

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

Главная область применения таких приложений – мобильные устройства. Пользователю больше не нужно входить на AppStore или PlayMarket , чтобы скачать программу – все сделает браузер автоматически (а еще создаст ярлык на рабочем столе, позволит работать с собой без доступа к сети и т.д.). Фактически, мы получаем аналог обычного приложения с тем же функционалом и множеством плюсов (для PWA не требуется лишняя память смартфона, ради которой приходится удалять фото и видео, они весят менее 1 Мб).

При появлении нового контента PWA отправляет пользователю push-уведомление. Следует признать, что в скором времени эти приложения смогут заменить практически все мобильные аналоги. Хоть технология и появилась в 2007 году в компании Apple , изначально она «не зашла» в силу слабой «прогретости» публики, зато ко второй половине 2016 года Google развил ее и сделал популярной.

PWA-версии приложений встречаются у многих компаний (тот же Aliexpress почти в 2 раза повысил конверсию от новых посетителей благодаря этому).

Перечислим основные преимущества и недостатки SPA , MPA и PWA приложений:

Источник статьи: http://smartiqa.ru/courses/web/lesson-1