В последнее время я задаюсь вопросом, не пора ли изменить то, как мы думаем о браузерных приложениях (или веб-приложениях).
Я трачу много времени на написание кода, и пара недавних проектов помогла выявить некоторые умственные ограничения, с которыми я бессознательно жил последние несколько лет. То, как я вижу веб-приложение, сегодня изменилось. Может быть, я опаздываю на вечеринку, но, возможно, кому-то еще нужно обновить свое мышление.
Я относительно свободно называю себя full-stack разработчиком. Я знаю несколько серверных языков, таких как Python и PHP, и я неплохо разбираюсь в Javascript, и я знаю, как собрать сервер, установить на него ОС и другие полезные вещи и защитить его от большинства разумных угроз. Я помню все сетевые уровни и то, что UDP быстрее, чем TCP/IP, и почему, и я только хотел бы вспомнить, почему разрешения Windows кажутся почти точно перевернутыми по сравнению с Novell 3. Я всегда в курсе большинства последние новости ARIA, HTTP, CSS и Javascript, у меня есть некоторый опыт поиска ответов, которые никто другой в моем техническом кругу не может, и я могу справиться с определенной творческой обязанностью (хотя дизайн, безусловно, мое слабое место).
Безусловно, самым сложным для меня было изучение объектно-ориентированного программирования.
Я выучил Бейсик, когда мне было 8 лет, начал изучать язык ассемблера примерно в 12 и запомнил все действительно полезные ячейки памяти Commodore 64 в школе и Apple ][ дома. Я выбрал Pascal, какой-то странный язык баз данных на TRS80 Model 3 и C. Что общего? Все процедурные языки.
С тех пор, как я познакомился с ООП, я никогда не чувствовал себя с ним как дома. Это всегда казалось ненужным слоем абстракции над тем, что должно быть очень простым кодом.
Как и все, чем больше я заставлял себя использовать его, тем больше я к нему привыкал. Я изучил Java, некоторые более современные C, Python, Javascript и PHP — все языки, которые в той или иной степени поддерживают ООП (теперь в большей степени, чем когда я их изучал). Все они имели разный уровень полезности и элегантности, но ни один из них, так сказать, не открывал окна.
Я понимаю полезность ООП в проектах, я понимаю, почему его легче поддерживать в долгосрочной перспективе, особенно в крупных проектах, и я согласен с тем, что правильно спланированная система позволяет нескольким разработчикам очень легко работать над вещами в тандеме.
Я думаю, что меня буквально втянуло в 21 век веб-разработки, и мне это нравится.
Однако через эту призму недостатки гораздо более очевидны. На самом деле большинство проектов не очень хорошо спланированы, разработчики всегда наступают друг другу на пятки, и как бы вы ни старались, кто-то где-то начнет добавлять технический долг, и со временем он будет накапливаться.
Очень немногое из этого имеет непосредственное отношение к тому, что я собираюсь сказать, но я описал это, чтобы показать мое состояние ума, когда дело доходит до веб-разработки. Я устроился. Я думаю, что есть лучший способ усвоить и описать архитектуру программного обеспечения для Интернета, и я думаю, что на самом деле это может быть MVC.
Браузер — это окно, через которое приложение взаимодействует с пользователем. Именно здесь компонент «представление» будет жить и умирать.
Мы не передаем представление в браузер, мы передаем в браузер данные, которые затем оборачиваем различными фрагментами HTML и CSS, возможно, присоединяем некоторые прослушиватели Javascript (контроллеры) к определенным событиям, а затем позволяем браузеру делать свое дело.
Всякий раз, когда данные изменяются, URL-адрес в адресной строке также должен меняться. Таким образом, пользователь всегда может добавить в закладки ваше приложение, где он находится, и получить свое состояние в другое время и, возможно, из другого места — данные не хранятся в браузере постоянно.
Таким образом, сервер должен содержать компонент модели. Контроллеры, работающие в браузере, не взаимодействуют с моделью напрямую, равно как и представления. Там есть еще один слой — домен. Когда браузер имеет подключение к Интернету, домен может взаимодействовать с моделью на сервере. Если соединение обрывается, домен должен иметь возможность возвращать кэшированные данные или передавать исключения вверх по цепочке до тех пор, пока они не будут обработаны и отображены представлением.
Первоначальный запрос к этому браузерному приложению вызовет следующие действия:
- браузер запрашивает версию приложения, затем загружает новую версию, если это необходимо
- приложение запускается, проверяет браузер на наличие информации о состоянии (например, файл cookie сеанса), а затем отправляет это состояние на сервер
- если это состояние существует и имеет данные, оно отправляется с сервера на контроллер(ы) приложений.
- приложение обновляет браузер представлениями в зависимости от текущего состояния
Теперь, когда приложение запущено в браузере, будущие запросы могут инициировать следующие действия:
- пользователь нажимает ссылку на страницу
- контроллер запрашивает у домена страницу XYZ
- домен запрашивает модель (сервер) для страницы XYZ в текущем состоянии
- модель отправляет обратно данные, содержащие страницу XYZ и любую запрошенную мета, связанную с ней
- домен отдает данные контроллеру
- контроллер строит представление и сообщает браузеру обновить экран
Но подождите, скажете вы, разве такие системы, как Angular и React, уже не побуждают вас писать?
Ответ положительный, но их терминология мне непонятна. Если вы не согласны с локальным хранением данных, чтобы никто другой не мог их увидеть, компонент модели не может быть расположен на клиенте — он должен ссылаться на сервер. То, что Angular называет моделью, на самом деле больше похоже на домен — в конечном итоге вам нужно написать код, чтобы подключить его к вашему серверу, который является вашим фактическим слоем модели.
Всегда будет определенное количество споров о том, где должны быть определенные типы бизнес-логики, поэтому я не хочу касаться этого здесь. Я только понял, что если сервер рассматривать как модель, мне становится намного легче вникать в компоненты контроллера и представления. Я также получаю преимущество в том, что могу использовать язык, наиболее подходящий для работы — Javascript в браузере (который может быть скомпилирован из TypeScript или другого языка) и Python, PHP или что-то еще на сервере. Поскольку единственное соединение обрабатывается через REST или Graph API, мне нужно только разделить мою модель на 2 уровня — домен (потому что, возможно, я храню данные как в MySQL, так и в Redis — все равно понадобится интерфейс над моделью) и контроллеры для обрабатывать поступающие запросы. Гораздо проще!
Я с нетерпением жду написания чего-то, что представляет собой MC на сервере и VC на клиенте. Интересно, есть ли «MC/VC»…
