«Должен ли я начать этот новый проект с внутренней структуры?… Или с внешней структуры?…»
Этот вопрос пришел мне в голову несколько дней назад, во время обсуждения проектов, над которыми я работаю. Как разработчик полного стека мне приходилось сталкиваться с обоими видами фреймворков, и я должен сказать, что это не из легких.
Быстрый ответ - «начни с того, что знаешь». Но с ростом опыта растет и область знаний разработчика. Вы приобретаете навыки во все большем количестве вещей и можете задавать себе все больше и больше вопросов, прежде чем начинать новый проект. Вы становитесь разборчивым.
Итак, вот мое руководство по принятию решения, собираюсь ли я начать с проекта VueJS или проекта Symfony. С проектом React или с проектом Laravel. Но сначала я резюмирую характеристики обеих вселенных.
Хранилище данных
Будет ли ваше приложение позволять пользователям создавать данные для совместного использования с другими клиентскими устройствами? Если ответ отрицательный, используйте интерфейсную структуру. Именно так мы поступили при разработке BROMSE. По сути, это метапоисковая машина, предназначенная только для книг. Пользователям не нужно входить в систему, ничего о них и их поисках не сохраняется, поэтому нет базы данных. Список книжных магазинов представляет собой простой файл JSON на нашем сервере.
Но если ваше приложение действительно должно позволять пользователям создавать данные, серверная структура не обязательно является подходящим решением. Конечно, ваш код будет ближе к «источнику истины», почти всегда на одном сервере. Внутреннее приложение напрямую связано с базами данных, поэтому лечение выполняется очень быстро.
В случае интерфейсного приложения данные могут храниться на стороне клиента с помощью таких инструментов, как Веб-хранилище или IndexedDB. Но он может быть удален, если вашему веб-браузеру требуется место, или может быть некорректным, если вы используете несколько веб-браузеров. Это не данные, которые можно назвать постоянными. Вам нужно будет использовать удаленную базу данных, если вы хотите, чтобы ваш пользователь не потерял свои данные или если они хотят поделиться ими между устройствами. И для этого есть масса хороших сервисов, таких как Firebase, Backendless или Parse. Этот последний вы даже можете принять у себя, если хотите.
Вычислительная мощность
Для интерфейсного приложения вычислительная мощность - это то, чего вы, как разработчик, не можете себе позволить. Независимо от того, запускают ли ваши пользователи ваше приложение на дешевом планшете или на ультрасовременном компьютере, взаимодействие с пользователем может полностью измениться. Поскольку он не скомпилирован для машинного языка, тяжелые вычисления в JavaScript неэффективны, поэтому я советую избегать этого.
Серверные приложения на другом конце будут работать на выбранном вами сервере. Так что вы должны знать, на что он способен. И у вас есть право обновить его, если он станет медленным. Такие языки, как PHP, также не компилируются, но поскольку вы контролируете машину, на которой работает ваше приложение, вы можете писать функции на C (просто пример), скомпилировать их в машинный код и вызывать их из вашего PHP. Это хороший способ ускорить тяжелую обработку.
Пользовательский интерфейс
В наши дни приложения имеют тенденцию встраивать все больше и больше динамических элементов. Конечно, если вы решите использовать интерфейсную структуру, вы, вероятно, нацелитесь на одностраничное приложение (SPA), которое полностью динамично.
Если ваше приложение в основном состоит из форм и таблиц для управления данными, например, CRM (менеджер по работе с клиентами), серверная структура будет отличной! И вы всегда можете добавить что-нибудь динамическое, вставляя немного JavaScript с места на место. Фреймворк, такой как VueJS или React, может даже использоваться в сочетании с серверным фреймворком, но не для создания всего приложения, а просто для создания некоторых динамических компонентов для использования на нескольких страницах.
SEO
SEO - это важная вещь, которую нужно учитывать. На содержание одностраничного приложения не будут ссылаться должным образом, поскольку роботы Google не активируют JavaScript. Контент в основном недоступен для ссылок в поисковых системах.
Так что, если поисковая оптимизация является для вас чем-то важным, например, если вы создаете платформу для блогов, используйте приложение внутренней инфраструктуры.
Сотрудничество в реальном времени
Это то же самое, что и динамические пользовательские интерфейсы. Совместная работа в реальном времени, как в документах Google, где вы можете видеть курсоры каждого участника, возможно, является основной функцией для вас. А это значит, что пользовательский интерфейс нужно постоянно обновлять. Или, может быть, вам нужны уведомления в приложении в реальном времени?
Хотя этот вид функциональности может быть добавлен позже во внутреннем проекте с использованием некоторого JavaScript, вызовов Ajax, веб-сокетов ... Если вы начинаете новый проект, я бы посоветовал использовать интерфейсную структуру. Таким образом будет намного проще взаимодействовать с данными на стороне клиента и синхронизировать их с серверной базой данных в фоновом режиме.
Что выбрать?
Что ж, для некоторых случаев это не проблема. Вам нужно SEO? Вам нужно хранить данные? Все ли это динамично, как в приложении для совместного рисования?
А некоторым бывает сложно выбрать… Вы хотите SPA, но в серверной части SaaS отсутствуют некоторые важные для вас функции. Или вы разрабатываете CRM для совместной работы в реальном времени. В этих случаях вам, возможно, придется разработать свой собственный серверный интерфейс в форме API, а также запустить интерфейсный проект.
Я надеюсь, что это было полезно. Спасибо, что прочитали меня. Хорошего дня!
