[:en]Do we still need a server? P2P distribution for Web applications[:ru]А нужен ли нам сервер? P2P распространение Web приложений[:]
[:en]Isomorphism – is an ability to run the same code and generate UI on server side as well as on client. It owes it`s appearance to the power of Node to run server side Javascript and became really popular in recent years after ReactJS established. Isomorphism is one of the hottest and on demand topics in Web development at the moment. This is right time to assess it`s value and effect and to review isomorphism as a one more leap towards new kinds of architectures and solutions. This article is a dive into one of them – viral Javascript technique which is used for Web applications P2P delivery.
Because of current demand isomorphism got awesome and powerful tooling. Most popular isomorphic toolset is Express server framework which delivers apps to client and React UI library which allows to render components to DOM for being executed in browser as well as to HTML string for being executed on NodeJS server. And if Express barely have any alternatives there are a lot of competing isomorphic UI libraries. However does not matter which one you use the essential of isomorphism remains the same and the most significant achievement here is an unification of codebases between server and browser. The boundaries between them are blurred by isomorphism and the only difference now is not a codebase specifity but server`s ability to deliver application to clients. And what if we go further supposing that client can deliver application to others? What if we can erase the boundaries between server and client completely? In this case every client which got application`s code becomes it`s distributor or carrier. And drawing the analogy with spreading microorganisms in the nature this technique perfectly matches “viral Javascript” naming.
P2P content distribution allows to reduce server load which is going to be interesting for social and non-profit organizations and projects, also this may decrease network latency since peering could be set up in the way content to be delivered from the nearest peer available. For example after hitting corporative network application will be delivered inside of it using high speed internal channels without creating a load on company`s internet channel.
Pic.1 – Traditional app distribution. Server sends package many times, corporative internet channels are loaded appropriately.
Pic.2 – In case of P2P distribution application hits corporative network once and then is distributed using high speed internal network. This reduces server load and corporative internet channel load.
Or another case – once application got from USA to Europe it is delivered inside of European networks only without creating transatlantic traffic.
Pic.3 – It takes a lot of transatlantic trips to transmit an app when doing it in a traditional way.
Pic.4 – P2P allows to reduce number of transcontinental transfers and reduce server load.
By distributing application via P2P you create a self-establishing and self-evolving CDN which moves data closer to client.
How does viral Javscript work?
– When server receive a request for an app it determines are there any peers available nearby the requester.
– If there are no matching peers client receives full application code from server and small viral script (viral addition) is added to the end of application code. Viral addition executed on client after app transferred completely. It connects to server and notify server about one more peer available. Also viral addition is responsible for serving P2P requests from other clients, basically this is a code which send application to next peer;
– If server finds a correct peer it respond with a minimalistic script (thin client) which contains instruction to connect with peer X`s viral addition, receive application from there and deploy it locally;
– Server helps seeding peer and receiving peer to exchange P2P addresses;
– They establish direct connection and carrier sends application to the recipient;
– Recipient executes code it received which launches application and makes him one more active peer.
Algorithm is simple enough but requires pretty a lot of code to run and some details to be taken into account: How to send static files? How to cache content? How to render app on carrier? How to exchange P2P adresses? Easy answer to all of them can be ViralJS.
ViralJS is a ready to use viral container implementation. To start distributing your app through P2P it is enough to include ViralJS into your project and use it as Express middleware:
var ViralContainer = require('ViralJS');
var viralContainer = new ViralContainer();
app.use(viralContainer.middleware);
Also ViralJS have an API for messaging from carrier to recipient and signage of transmitting content. So for sending object to recipient you may call
ViralContainer.writeMeta(someObject);
, and recipient may read this data via
ViralContainer.meta
Conclusion
As you see it is a few lines of code to convert your app into P2P distributable one. As on today P2P messaging between browsers (WebRTC technology) is supported by Firefox and Chrome. Microsoft and Apple gave a promise to add WebRTC support to their browsers by the end of 2015. Even now there is a fallback which does not reduce quality of delivered app – Safari and IE/Edge will just receive regular application without viral addition which means that there is no compatibility problem when start using P2P distribution. As we said before – P2P Web is interesting from infrastructure cost and latency reducing perspective, but also viral Javascript it is an inspiring foundation for next quality leaps for brand new, experimental Web architectures and solutions. However even it is amazing opportunity to move forward the answer to the question from title is: “Yes, we still need a server to make initial distribution and signaling between peers.”[:ru]Изоморфизм — возможность исполнения одной и той же базы кода на сервере и клиенте. Своим появлением он обязан возможности исполнять серверный JS с помощью Node.js, а по настоящему популярным стал благодаря распространению React. На данный момент изоморфизм — один из самых горячих и востребованных трендов Web разработки и это лучшее время что бы оценить последствия его появления, рассмотреть изоморфизм как ступень к совершенно новым архитектурам и решениям. В этой статье рассматривается одно из них — виральный Javascript применяемый для P2P распространения Web приложений.
Благодаря текущей востребованности изоморфизм оброс инструментами. Самыми популярными из них является Web сервер Express используемый для доставки приложений клиенту и UI библиотека React позволяющая рендерить компоненты как в DOM в браузере, так и в строковый HTML на сервере. И если использование Express является практически безальтернативным, то клиентских библиотек поддерживающих изоморфизм существует достаточно большое количество, однако вне зависимости от того какую из них вы выбираете основная концепция изоморфного кода не меняется. Главным достижением изомофрного JavaScript стала унификация кода в браузере и на сервере которая практически размыла грань между ними. Теперь основным различием клиента и сервера становится не специфичность кода, а возможность сервера раздавать контент. Но что если пойти дальше изоморфизма и предположить, что возможна передача приложений с клиента на клиент? Что если мы можем полностью уничтожить разницу в функциональности серверного и клиентского кода? Таким образом каждый клиент получивший код приложения становился бы его распространителем или носителем если провести аналогию с распространением микроорганизмов в природе, а самой технике неплохо подходит название виральный JavaScript (Viral Java Script).
P2P распространение контента позволяет уменьшить нагрузку на сервер, что будет интересно общественным организациям и некоммерческим проектам, а так же уменьшить задержки при доставке контента ведь пиринговая сеть может быть настроена таким образом что бы контент поставлялся с ближайшего доступного узла. Например единожды проникнув в корпоративную сеть предприятия приложение будет распространяться внутри по корпоративным, высокоскоростным каналам связи не нагружая интернет-канал предприятия.
Рис.1 — Традиционное распространение приложения. Сервер отдает пакет множество раз, интернет каналы предприятий загруженны пропорционально.
Рис.2 — При P2P распространении приложение попадает в корпоративную сеть предприятия и далее передается от компьютера к компьютеру по внутренним каналам связи. Это уменьшает загрузку сервера и использование интернет — канала предприятия.
Или единожды попав из США в Европу приложение будет распространяться внутри европейских провайдеров не совершая трансконтинентальных путешествий.
Рис.3 — При обычном способе распространения пакету приходится изрядно попутешествовать, если клиент находится на другом континенте.
Рис.4 — P2P модель распространения позволяет избежать множественной трансконтинентальной передачи приложения.
Распространяя веб приложение через P2P вы переносите его ближе к клиенту, строите самоподдерживаемую и развивающуюся CDN.
Как работает виральный Java Script?
- При запросе от нового клиента сервер определяет есть ли рядом с запрашивающим доступные пиры (носители)
- Если подходящих носителей нет — то приложение отдается полностью с сервера, а в конец приложения дописывается виральный скрипт (Viral Addition). Viral addition исполняется на клиенте после получения приложения и отправляет на сервер информацию о том что текущий браузер стал носителем приложения. Сервер добавляет его в список доступных пиров. Так же Viral Addition отвечает за обработку P2P запросов от новых клиентов;
- Если же сервер находит подходящего носителя рядом с клиентом, то отдает не все приложение, а лишь минимизированый скрипт (Thin Client) с инструкцией «запросить приложение у носителя Х и развернуть локально»;
- Сервер передает носителю P2P координаты клиента, а клиенту координаты носителя, благодаря чему они устанавливают прямое соединение и клиент получает приложение с носителя;
- Клиент разворачивает скрипты приложения, тем самым завершая запуск и становясь еще одним носителем.
Схема работы достаточно проста, однако требует определенного количества кода для реализации и учета ряда ньюансов: Как передавать статические файлы? Как кешировать контент? Как рендерить приложение на носителе? Как связать носителя и получателя для обмена ID? Простым ответом на все эти вопросы может стать использование ViralJS.
ViralJS — готовая к использованию имплементация вирального контейнера. Для того что бы начать распространять ваше приложение через P2P достаточно подключить ViralJS в проект и добавить его, как middleware к вашему ExpressJS приложению:
var ViralContainer = require('ViralJS');
var viralContainer = new ViralContainer();
app.use(viralContainer.middleware);
Так же ViralJS имеет API для передачи сообщений между участниками системы и подписи передаваемого от носителя к получателю контента. Для того что бы передать объект получателю достаточно в коде сообщения вызвать
ViralContainer.writeMeta(someObject);
, а на носители обратиться к этим данным через
ViralContainer.meta
Заключение
Как видите сделать ваше приложение виральным достаточно просто. На сегодня передача P2P сообщений между браузерами (технология WebRTC) поддерживается Firefox и Chrome, а Microsoft и Apple обещают внедрить API в ближайшем будущем. Даже сейчас имеется фоллбек который не ухудшает качество приложения относительно исходного — пользователи Safari и IE/Edge получат от сервера обычное Web приложение и проблема кроссбраузерности по факту отсутствует.
Как уже говорилось выше — P2P Web интересен с точки зрения уменьшения издержек на серверную инфраструктуру, оптимизации пути проходимого приложением, но больше всего вдохновляет для экспериметов и которые открывает виральный JS и перспектива следующего шага, но не смотря на это ответ на вопрос из заголовка будет «Да, нам все еще нужен сервер для первоначальной раздачи и координации P2P сети.»[:]