Do we still need a server? P2P distribution for Web applications
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.”