Introduction
Today I would like to speak about an alternative way of implementing front and backend web servers. This method is based on WebSockets communication mechanism. Please keep in mind that this is just a concept work, although currently I’m trying to make use of it in one of commercial web pages that I’m currently working on. My client agreed to make this experiment and the accepted even possible failure.
The whole idea was born after watching the video on YouTube ( https://www.youtube.com/watch?v=6v4E6oksar0 ). In an introduction chapter the presenter covered some issues and weak points of current webdev technologies in 2017. Unfortunately when I went through the basic concepts of WebAssembly I understood that this is not what I was looking for, and here comes why this idea came to me.
Technical details
The very first standard of WebSockets has been published in 2011, so this technology is quite well supported by each popular web browser.
Since 2011 the JavaScript language was evolving and a new implementation named NodeJS shown. Because of that fact languages like PHP or Ruby lost some popularity among web developers. There were strong reasons to use NodeJS, like very high performance of V8 engine or “bad press” for PHP.
As the time progressed more and more developers started complaining about some quirks or design flaws in JavaScript. That problem has been partially covered by NodeJS with it’s very fast V8 engine and ES6 standard, but still – developers wanted something different. This is how WebAssembly has been created. A low level language, which is not suitable for writing a code “by hand” because it’s syntax is based on mnemonics and operands known from assemblers. A different compilers been created that were able to transpile C or C++ code into WebAssembly (WASM) code. Such binary code is being loaded then by JavaScript into web browser engine and executed with the speed almost equal to a native code.
This solution however has some limitations. Theoretically it is possible to develop the whole frontend let’s say in C# or C++, but for now there is no such framework (alright, it is – https://github.com/mbasso/asm-dom but it is in an early stage and not production quality).
The solution, that is solving similar problems, but without WebAssembly is the presented here. It is a WebSockets based server written in C++ implementing SSR (server-side-rendering). The difference is that WASM code is being executed on the client side, while my solution will allow server side execution (just like an old fashioned PHP).
This assumption of server side execution is not a limitation, but just an architectural decision. You can of course write some part of code using WASM and expose the binary file to the client, so he can run the program on the web browser using the processing power of the CPU of the client, not the server.
On the diagram you can see the following blocks:
- PageRouter: It is a class that is doing the routing of client requests into page renderer.
- PageTemplate: It is a server side page template. The template is being loaded into an address space of the server process on the server machine.
- PageRenderer: This is the renderer of web pages. It takes a client request and completes the web page into a single stream of bytes. Then it is being sent back to the client using WebSocket connection.
The server created this way will take care of almost all aspects of web application stuff. This architecture will let you to marginalize use of JavaScript in an entire app. Couple lines of JS code has to be added for let’s say HTML5 elements, but it is not a very large code base.
Pros:
- Server is a native application, much better performance of page rendering.
- Each web browser released since 2011 will handle such web application.
- A modern, strong typed language and advanced technology of Qt (see next chapter).
- We decrease use of JavaScript.
- Much better scalability using multi-threading in Qt, no limits like Python GIL or single threaded V8 engine.
- A very wide available frameworks and libraries for image processing, machine learning etc.
Cons:
- Relatively big initial effort to learn C++ and Qt for typical PHP/JS developer.
- No existing frameworks at this point using similar approach.
- Potential security issues, encryption has to be implemented using SSL libraries or Qt.
- A major part of the application is being executed on the server side. This might cause a server overload and/or raise the costs of application.
Why C++ and Qt
My primary programming language is C++ and I like all that quirky stuff (well, to the some degree). However the whole idea was born because I’m a pragmatic guy. During my professional career I created many web applications using several different technologies and approaches like PHP, Ruby on Rails or NodeJS and the main issue was always JavaScript. That was especially driving me nuts when writing a backend application and some data from database had to be processed or when implementing frontend DOM operations. The other reason is that I just simply dislike a lot the “ergonomics” of JavaScript language.
In the C++ world the most mature framework is boost and Qt (although these are two distinct frameworks). Using Qt makes the development of desktop applications much easier and straightforward. You could compare it to C# and WinForms while at the same time maintaining the blazingly fast native code execution performance. Forget about raw pointers or tough multi-threading synchronization issues. The whole application is working asynchronously (single thread) same as NodeJS, but nothing can’t stop you from creating threads, thread pools and even maintain them by hand (something like fibers).
Why not WebAssembly
WebAssembly has not been designed to replace JavaScript, but to extend it’s possibilities and increase performance of web applications. I tried to adapt this technology in a production application, but for now it is just a toy and long road is ahead WebAssembly. It is more suitable to write a single C language function and to compile it using Emscripten then load the resulting .wasm file into web browser and execute the code. The only problem is that you end with a pretty long list of steps to get through and each step may potentially create a bug or regression.
The goal of this project was to reduce areas where JavaScript is actually required and to use statically typed programming language for web development.
Target application area
An area of application for such technology are web applications that are processing a lot of data, video or graphics etc. The end device could be potentially a thin client or terminal equipped with a low power CPU and relatively slow GPU.
The presented approach could work also in a regular web applications where performance is not that important, but there are gains of using statically typed language. Another gain is that you actually don’t need to enter the world of web application development, you’d still live in a C++ world, so no need to invest any extra time (and money) for learning stuff that you won’t need in the future.
License and legal situation
I consider here two operating systems – Linux and Microsoft Windows. On FreeBSD you need to use a special Qt repository with some patches applied to successfully compile Qt using CLANG toolchain. The releases of that repository are not as frequent as for platforms officially supported by Qt.
Microsoft Windows:
- Microsoft Visual Studio 2017 or 2019, Community License (free for commercial use up to 5 developers or up to limit of 1 million dollars of revenue each year including companies under 250 developers).
- MINGW toolchain – a little bit slower than MSVC (both compilation and runtime). Free, no limits at all.
Linux:
- G++, free, no limits.
You may use Qt LGPL license as long as you link your program dynamically (this is the default behavior). No official support from Qt, only community forums (I’d say it’s enough most of the time).
What’s next
Currently I’m working on the very first application using this approach. I’m also considering to open the source code of the framework and switch to MIT license. The initial approach is to just write a solution that could potentially generate a simple HTML page while maintaining the reduction of JavaScript code – I want to hide what’s ugly and uncomfortable to use.