Какой лучший подход к разработке SPA?

Question

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

Answer 1

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

Монолит: Приложение, в котором внутренний и внешний код живут в одном проекте.

Что это значит: Кодовая база проста в обслуживании, потому что там все в порядке. Вначале есть меньше сложностей и гораздо меньше времени на производство, потому что легче «выйти за дверь». У вас нет сложностей, например, как разные части «системы» разговаривают друг с другом и т. Д. Здесь начинаются все стартапы.

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

Внешняя ссылка & API: Приложение, в котором интерфейсный код и API живут отдельно в разных кодах. API предоставляет только данные, обычно в формате JSON, в котором код интерфейса используется и отображает эти данные.

Что это значит: Теперь, когда вы нарушили API и интерфейсные базы кода, вы можете использовать API для предоставления данных для ЛЮБОГО интерфейсного приложения, которое в нем нуждается. Например, подумайте о сети и мобильных устройствах. Они могут использовать один и тот же API. Для более крупного приложения это становится намного более удобным, и теперь вы можете создавать команды как для внутренних, так и для интерфейсных процессов. Теперь вы можете добиться лучшего масштабирования и эффективности, поскольку проект растет.

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

FEBE & Микро-услуги: приложение, в котором все части «системы» живут в очень зашифрованных кодовых базах, архитектуре и т. д. FEBE - это «интерфейсный сервер», а микросервис - это сервис (может быть API), который обслуживает ОЧЕНЬ конкретную функцию внутри бизнес-логики. Для этого в интерфейсе в этом мире может потребоваться несколько микросервисов.

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

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

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

Мой совет таков: Начните с монолита с использованием внешнего блока Node.js (Express) и либо с React.js, либо с угловым интерфейсом.

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

Когда вы переходите к Фазе 2 (интерфейсный интерфейс и API), придерживайтесь Node.js и, вероятно, реагируйте в этот момент. Или, если бы это был я, я бы просто использовал данные API в Handlebars и делал с ним (вообще не используя интерфейсную инфраструктуру).

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