The Building of Yeww: A WebRTC ProjectChoosing Technologies

Posted on September 11, 2016 at 4:55 PM by Lynn Walker

If you’re getting itchy to code, be patient a little while longer. We’ve almost reached our first lesson involving code. Just a few details to clear out of the way first, starting with which technologies to use.

Technology Needs

Let’s briefly review what the web application, yeww, needs to do.


Provide secure authentication for access to non-public pages and secure data storage from intrusion.


Designed scalable.

Responsive UI

UI is responsive both in terms of an adaptive display as well as in immediate response to user actions.

Real-time Interactivity

The application must support real-time functions, such as messaging or live update feeds.


In the future we believe we will want the application to handle files and actions like sharing, versioning and collaborative editing. Our technologies must allow us to extend our project in those directions.


Since quality testing is the guarantee of a quality product some of our technologies will be for testing and monitoring activities. The rest need to play nice with testing.

Selection Priorities

The first priority for any of our technology choices is that it must be capable of doing the job.

I will choose from what I know over that which is unfamiliar. It’s common sense that choosing from what I know will save time. Since my knowledge stores are vast, we don’t need to worry that we’re limited. snicker.

Cost of hosting the final product. You should always be conscious of costs, but this time we’re going to push the concept to an extreme. Hosting costs may force our choice of development platform, or they might bear the kind of fruits born of out-of-the-box thinking.

Development Platform

My choice would be to use ASP.NET Web API to create REST API’s to provide access to our data which is stored in either MS SQL or mongoDb. AngularJS for the client side, UI designed with Bootstrap.

Setup chat server using node.js and Add video chat capability with vline.js or peer.js. Test with karma, jasmine, protractor and selenium webdriver. Code coverage and reporting support with node modules for karma. Continuous Integration with Jenkins and SonarQube for analysis.

Hosting Cost Considerations


I have a Windows hosted account at, which allows unlimited domains, storage and bandwidth, but no root access or administrator privileges. MySQL databases are available as well as a very limited quantity of MS SQL Server instances.

Godaddy is primarily useful in handling traffic to a static html or a php page. I can’t host node.js at Godaddy. I can’t host ASP.NET web services I create. I could host REST API’s using PHP and MySQL, and while not my preference, could be a possible fall back solution.

Amazon Web Service

For root level access to a server I use Amazon Web Services free-tier, which provides me with a year of free use of one Linux and one Windows box, with very minimal resources. It’s sufficient for development, but I don’t expect I could serve many concurrent video chats from the free-tier boxes.

The question for now is, can I at least get the level of performance from the AWS Windows Server instance to host a MS SQL Server instance and the REST API endpoints to it? If so, then our technology choices can be finalized. If not, then I will need an alternative to ASP.NET and MS SQL Server for the database and web services portion of the solution. Everything else will be running on a Linux server.

Proof of Concept

I like to stack the front of the project with proof of concept development. Crude, bare bones demonstration of solutions to the most difficult technical challenges in the project.

Testing Server Resources

One need is to test our server resources to see if they can handle a video chat, and a web service exposing a MS SQL Server database.

Demonstrate Engineering Solution

Another need is to demonstrate our engineering solutions, to confirm that they can provide the solution for which they were selected.

In order to accomplish both of these objectives we need these proofs:

  • A web service that can authenticate a user for login running on the AWS Windows Server.
  • A node.js instance supporting chat between two concurrent users on the AWS Linux Server.
  • A node.js instance supporting video chat between two concurrent users on the AWS Linux Server.

The thinking is, these represent the trickiest of our development tasks, so let’s prove that we know how to deal with them as our first objective. Once we’ve provided a proven solution for each of these, we’ll have confidence that the rest of the project is quite easily done.