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

Так здорово! Мне не нужно постоянно переключаться между языками. Это мило! Что теперь?

Этап 1. Общая конфигурация

Я знаю! Я возьму некоторую информацию о своем приложении и засуну повторно используемые значения в файл, который будет использоваться как на стороне клиента, так и на стороне сервера:

ОК, круто! Теперь я могу просто импортировать файл как на сервер, так и на клиент, и я больше никогда не буду повторять название своего приложения! славный.

Этап 2. Общие коммунальные услуги

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

Этап 3. Общая бизнес-логика

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

Этап 4. Реализация полиморфной отправки на платформу

В значительной степени разработка этапа 3. Если мне нужно получить что-то с внешнего URL-адреса, я могу не зависеть от XHR и заставить его работать где угодно.

Этап 5?

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

Можем ли мы создать полностью абстрактный уровень одноранговой связи, где одноранговым узлом может быть сервер или клиент (или родное приложение)? Да, конечно, у нас есть WebSockets! Это означало бы, что у нас может быть абстрактный уровень пользовательского интерфейса и уровень абстрактной логики/постоянства, разделенные уровнем связи, и все они работают как на сервере, так и на клиенте.

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

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

Что думаете? Это невозможно? Это вообще хорошая идея? Каковы были бы варианты использования для этого? Будет ли это означать слишком много работы, чтобы получить слишком много сложности?