Understanding Tufão, part 1

This post is dedicated to Tufão, but before talk about Tufão, I’ll tell a small preparatory text. Once while surfing on the web, I found Node.js. What is Node.js? An excelent asynchronous JavaScript web API. Why is it excelent? It allows you write little code to do a lot of web-related things. There are lots of web frameworks in this level, but they usually don’t provide the right level of abstraction. Why not? They don’t support even old modern HTTP (the web protocol) like chunked entities and 100-continue, what about real modern HTTP features like WebSocket, WebRTC, among other then? You just can’t use modern features. You’ll have problems even with basic examples like doing live stream from a webcam. After this day, the day I knew a decent web API, I started to care about web development. And then, I created the Tufão project.

Tufão is a tool to work with web in C++. Why C++? I like C++ and this is enough to me, but there are other reasons to create a web framework for C++. First, computing is changing again. In the last years, the clock speed of the processors stalled and again, you need to care about performance. Not only that, but the nature of techniques to gain performance are changing too. Today, you find processor with more and more cores, you can see more general purpose enabled GPUs and there are more optimized instruction sets in processors. C++ is the right tool for the job, and with the language update in the last year, I believe that the language is becoming stronger. Second, I don’t see a de facto standard to create web applications using C++. Third, there are lots of good libraries and APIs in C++ that you can use to implement cool ideas and develop web apps in C++ would let you to use them.

So, instead of porting a not decent API to create a C++ web framework, I choose Node.js to create the API core. I believe that C++ programmers love controlness, so they will like the API’s power. Besides the core, I’m implementing other facilites to help in the use of application servers, file upload, forms parsing, WebSocket, WebRTC and other modern standards, web services, …

How does Tufão compare to other frameworks? In this post, I’ll compare it through some different points of view.

The programming language

My idea about programming language is that languages should be designed to express ideas, and if they don’t have a good expressive power, then they are useless. Today we have lots and lots of programming languages. Personally, I don’t like the direction the Java language is taking, but, on the other side, I like Python. I already see some languages created only to develop web applications. I don’t believe that this is a good move. I don’t believe that the web development’s problem is the lack of an appropriate language. There are lots of good languages available today and I don’t believe that create new languages is necessary.

I’m developing Tufão in C++. C++ has a good expressive power and the last year’s update improved it. The language isn’t popular among web development, but web development is very dynamic and change rapidly from time to time. How I said before, the problem, in my opinion, is not in the lack of an appropriate language, but in the lack of an appropriate framework.

Modules

Tufão can have extra modules as any other framework, but compared to Node.js, I see a problem with ease of the installation process. In Node.js, we have npm and all we need to do is npm install <module>, but in Tufão you need rely in the operating system installation process or compile the modules. This isn’t a problem in some GNU/Linux distributions like ArchLinux, but this might not be the case in other systems.

I don’t see an ease way to solve this problem, so I’ll try to evolve Tufão to be self-sufficient in most of the cases. And this isn’t really difficult as Tufão is built on top of Qt, that already provides lots and lots of common needed features to any application.

Routing mechanism

In Tufão, the rounting is built on top of two classes. The AbstractHttpServerRequestHandler interface and the HttpServerRequestRouter class. The AbstractHttpServerRequestHandler interface requires you to create a slot to handle a request and the HttpServerRequestRouter is itself is an AbstractHttpServerRequestHandler. This design let you to build things like nested routing and use the same router in several different combinations (serving to HTTP and HTTPS servers).

In Tufão, the basic building block for routing request is the same as several other frameworks. You just need to use regular expression to filter the path and pass a handler to that request, and, optionally, specify which methods the object will handle.

The plugin-based application server

Well, when you develop a web application, you want to do it available 24h per day, every day. Imagine how you’d feel if you had to stop the server, recompile the application and run it again just to add your company’s name at the bottom of the page.

We could just use a dynamic interpreted language and solve the problem, but the language isn’t the problem. In some web frameworks there is the notion of an application server, that usually is integrated in the routing mechanism. The role of the application server is to dynamically register new applications and remove old ones.

In C++, a dynamic handler is just a plugin stored in a shared library loaded at runtime by the application. It’s just the old *.dll files on Windows or *.so on Linux. Tufão provides an application server too, but, different from most of the frameworks I’ve seen, it’s not melted in the routing mechanism.

The Tufão application server is plugin-based, stores its configuration in a file (chosen by you) and provides an external program to update this file. It’s easy to use, but you’ll have to add code to define when the application server must reload the config file. If you don’t have any special requeriments, the default application template code is enough and you won’t need to write this piece of code at all.

MVC separation

Some frameworks just don’t separate logic and ui design, such as most of old PHP, embedding the logic code and the html (or some custom view language code) code in the same file.

There are frameworks that allow you separate the logic and the ui design, but do a wrong implementation of the idea, requiring the designer to have some knowledge about the framework internals, trapping you to use the tools from the same framework forever.

What is the idea of other frameworks? Other frameworks let you export application data to application ui design (through web services or other), allowing you to use any language to generate your HTML/CSS and import the data through JavaScript. This idea by alone don’t only help to lower the security problems (designers thinking about programming) and the application ugliness (programmers thinking about ui design), but also help to use HTTP features to decrease the network traffic needed by you application, making the use of cache more efficient (in HTTP level). How this happens? This is the old Ajax technique.

  1. Write ui design code in pure HTML, CSS and JavaScript and put the files in the public folder.
  2. Write logic to generate and serve the data in C++, without caring about ui design, and export the data in some format simple to import from JavaScript, like JSON.
  3. Write JavaScript code to import the data from the services and populate the views.

Using this technique, when the user access your site, the browser will request the pages server through the Tufão’s static file server, making most part of the page cacheable, saving precious network traffic from your application . Also, the view isn’t generated at runtime, so you will save server’s processing power too, increasing the maximum numbers of requests per second.

Another advantage is the freedom to choose technologies. The UI is just a bunch of static files, isn’t something chained to specific Tufão internals, so you can use any tool you want to create them. We don’t take away your freedom.

As an advice, you should implement each page handler as a plugin, so you can change the running code at runtime.

IDE

Web frameworks usually don’t develop custom IDEs and this isn’t an exception for Tufão. But, Tufão is built on top of Qt, and Qt programmers are used to QtCreator, so I created a QtCreator plugin to help the development of Tufão applications. The plugin just help to create new applications, providing application templates. I think this is enough, but if I change my mind, I’ll extend the plugin.

There are 3 application templates currently:

  • The first is a full featured web application, using the Tufão’s static file server, plugin server and a custom handler to treat 404-pages.
  • The second is a plugin that responds with a “Hello World” and is as small as possible to keep things simple.
  • The last is just a Hello World application.

Development time

Well, It’s not an easy task to measure the development productivity, but I can talk about some points. If what you want is a creative web app, you problably need a powerfull low-limited web API to help you, and my aim is to provide such API, so I highly invite you to test Tufão and give me some feedback.

If you plan to create some common-case application, there are frameworks such as Django that already provide several integrated facilities (such as mvc with integrated mapping of database schemas, template systems, already implemented authentacion sytems, … …) and right now, Tufão can only compete if you use other libraries to help you.

Improve Tufão to compete with Django isn’t my priority and I don’t even know if I care about facilitate the creation process of boring common projects, but is an important area and if the demand or the help increase, I’ll create tools to help in this use case too.

Framework’s future

Tufão is an open source project under the LGPL license. The documentation, examples and public headers are under the MIT license. This means that anyone can contribute to Tufão development and you can use it in your commercial projects.

I created Tufão all alone and tried to do I really good job in every piece of it, but maybe the documentation isn’t good enough, so if you have any question that cannot be solved reading the documentation, just ask me and in the next version the documentation might be better. The same rule applies to bugs (and I wrote lots of tests to prevent it, but I just didn’t realize how to automate all tests, like little endian and big endian tests…).

That’s it

In the next part of this article, I’ll demonstrate some benchmarks and how to create a web application using as much Tufão’s features as possible. Thank you for reading about the project, I really appreciate, and if you like the project, spread it among your friends.

I ackowledge Ryan Lienhart Dahl for developing Node.js. Before its API, I thought web development was tedious.

Tags:, , , ,

5 responses to “Understanding Tufão, part 1”

  1. Luís Gabriel says :

    Congratulations! It’s a very good initiative.😉

  2. psychomantys says :

    Some frameworks just don’t separate logic and interface, such as most of old PHP, embedding the logic code and the html (or some custom view language code) code in the same file.”

    Essa falacia aqui foi para me provocar né? xD

  3. marius says :

    Very usefull! I hope you’re still working on it.

  4. sailfishnewbie says :

    Republicou isso em sailfishnewbie.

Comentários (with MarkDown support)

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: