Как написать web приложение

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

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

Артем Галонский , технический директор «БюроБюро»

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

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

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

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

Андрей Черабаев , разработчик IT-компании MediaSoft

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

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

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

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

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

Михаил Чупаха , директор по развитию бизнеса в DAR

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

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

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

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

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

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

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

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

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

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

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

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

Как программировать веб приложения

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

С развитием Интернета и веб-технологий все больше приложений становятся веб-приложениями, т. е. из обычных нативных начинают работать и исполняться в среде браузера. Обычное нативное приложение как правило, пишется и компилируется на нативном языке программирования, например С или С++ и пишется под определённую операционную систему или на крайний случай под определённую виртуальную машину (NET Framework, Java, Python).

Веб-приложения же имеют совсем иной подход к написанию и работе. Веб-приложение имеет клиент-серверную структуру, клиентская часть которого исполняется в браузере, и которая посредством запросов общается с сервером). Таким образом, при написании веб-приложения необходимо реализовывать как клиентскую часть (браузерную, которая представляется в виде HTML разметки, CSS стилей, JavaScript кода, ответственного для соединения с сервером). И серверной части, которая должна обрабатывать запросы клиентов. Читайте также 10 топовых языков программирования для веб-разработки.

В отличие от клиентской части где языки программирования определены, (это язык гипертекста HTML и язык JavaScript) на стороне сервера может использоваться практически любой программирования.

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

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

навыки дизайна и разметки HTML страниц,
основы скриптового программирования с использованием JavaScript для взаимодействия с сервером и повышения интерактивности страниц.

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

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

ASP .NET — веб платформа от компании Microsoft. В последнее время microsoft активно двигает кроссплатформенную версию своей технологии под название .NET Core, которая может работать на любых операционных системах, а не только Windows как было до недавнего времени.

Python фреймворки и платформы. На Python работает популярная социальная сеть Instagram.

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

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

В настоящее время широко используется язык PHP, Python, Java, C#. конкретно используемый язык на серверной части зависит от выбора платформы или фреймворка, который используется на стороне сервера. Для высоконагруженных систем, типа банковских, широко используется на сервере виртуальная машина Java, .Net Framework. На более простых проектах типа стартовых интернет магазинов используется в основном PHP. Выбор того или иного языка зависит от постановленных задач, требования к потребления ресурсов, уровня подготовки программистов, которые будут данный проект реализовывать.

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

Источник статьи: http://webshake.ru/post/programmirovanie-veb-prilozheniy

Создаем современное веб приложение. Знакомство с проектом и подготовка к работе. Часть 1

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

Я пишу эту статью для начинающих Frontend разработчиков которые хотят создать свой первый JavaScript проект, и показать его всему миру Для этой серии статей я выбрал базовый стек который можно встретить в большинстве современных проектов. Чтобы не заскучать вы всегда можете добавить что-то свое, поэтому я рекомендую вам параллельно чтению статьи писать собственную реализацию и публиковать результаты работы на GitHub. Наверняка у вас есть десяток технологий, библиотек, фреймворков, инструментов, которые хочется попробовать, и разработка такого пет-проекта – это отличный вариант попробовать что-то новое.

Знакомство с проектом

Основная идея проекта, который мы будем реализовывать – написать библиотеку компонентов на React с TypeScript, документировать и визуализировать ее с помощью Storybook и опубликовать ее как пакет в npm. Также мы настроим линтеры, добавим тесты на Jest, автоматизируем процесс тестирования с помощью Travis CI. Возможно в ходе работы добавится что-то еще, не стесняйтесь комментировать и предлагать свои решения.

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

Начало работы

Для начала нам нужно создать репозиторий на GitHub для нашего проекта:

Так выглядит окно создания моего нового репозитория. Вам нужно придумать имя и небольшое описание вашего репозитория. Для всех своих пет-проектов я всегда выбираю публичный тип репозитория, но сейчас GitHub предоставляет возможность бесплатно создавать и приватный репозиторий если ваша команда не больше трех человек. Также я сразу добавил MIT лицензию – это самый простой и распространенный вариант лицензии для Open Source проектов, если вам интересно больше узнать про лицензии можете посмотреть этот сайт созданный GitHub.

Теперь клонируем новый репозиторий. GitHub предлагает клонировать с использованием SSH или HTTPS. Обычно я использую второй способ.

Если вы видите сообщения об удачной распаковке значит клонирование прошло успешно.

Также нам нужно сразу выполнить кеширование пароля, если это не сделать при следующих попытках сделать git push, git fetch, git clone вам будет необходимо вводить логин и пароль (Подробнее об этом).

Переходим к созданию файла package.json. Для этого выполним команду:

После выполнения команды в репозитории вы можете видеть package.json файл с некоторыми заполненными полями, мой выглядит так:

Внесем сразу небольшие изменения:

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

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

В двух словах что мы сделали: проверили историю изменений, проиндексировали измененный package.json, сделали коммит с простым и понятным коммит сообщением и после этого положили наши изменения в удаленный репозиторий. Теперь package.json и информация о новом коммите появились в нашем репозитории. Для работы с Git вы можете использовать IDE или GUI, но мне комфортнее делать все в консоли.

Линтеры

Чтобы ваш код был чище (это особенно важно если над проектом работает несколько человек) вам обязательно нужен инструмент для анализа и выявления ошибок. В своих проектах я использую ESLint для проверки JavaScript кода. Он прост в установке и гибко настраиваемый.

Настроим конфигурационный файл:

Вы можете сконфигурировать ESLint вручную или использовать готовый набор правил. Мне нравится гайд от Airbnb. Я воспользовался следующими настройками:

Так как мы планируем использовать TypeScript я сразу выбрал этот пункт в диалоговом окне, из-за чего получил ошибку Cannot find module ‘typescript’, что логично потому что TypeScript мы еще не установили, давайте сразу исправим это:

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

Чтобы проверить работу ESLint, давайте создадим файл index.ts и сохраним туда следующий код:

Отлично, код из 5 строк имеет 7 ошибок и 1 предупреждение. И сразу ESLint предлагает мне автоматически исправить эти ошибки, давайте попробуем это сделать:

И мы получаем такой код, без ошибок и с одним предупреждением о использовании console.log:

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

Я добавил опцию —write чтобы все отформатированный файлы перезаписывались. Проверим результат:

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

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

Pre-commit хук

Мы настроили ESLint и Prettier и создали скрипты для запуска вручную, но было бы хорошо делать это автоматически перед коммитом. Для этого мы можем воспользоваться Git хуками. Пакет Husky дает возможность запускать скрипты перед выполнением `git commit`, а пакет Lint-staged позволяет проверять только индексируемые файлы по определенным фильтрам.

Вернемся к package.json и добавим следующий код:

Теперь перед каждый коммитом мы будем запускать проверку ESLint и Prettier для всех измененных js и ts файлов и после форматирования добавлять эти файлы в наш коммит.

Давайте снова протестируем файл index.ts:

Только на этот сразу сразу проиндексируем этот файл и сделаем коммит:

Если вы сейчас проверите файл index.ts вы увидите, что код был отформатирован. Прежде чем сохранить изменения файл будет будет проверяться и при необходимости форматироваться. Это позволяет быть уверенным в корректности файлов которые попадают в ваш репозиторий.

Нам осталось сохранить все изменения. Перед этим создадим файл .gitignore куда запишем node_modules, нам не нужно чтобы папка с зависимостями попала в наш репозиторий. Также мы можем удалить файл index.ts, он нам в дальнейшем не понадобится.

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

На этом мы остановимся, всем спасибо за внимание, увидимся в следующих частях.

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