Express in C, a long ramble

A little more than a year ago, I started attended hackathons, first with Ambrose, then with the rest of MakerForce. Being in a team more than half of which consisted of programmers, it was natural that most of our projects consisted of some sort of app, specifically webapps for their ease of deployment and demonstration. Differing to someone with more experience, I followed Ambrose’s lead and used, and came to love, express.js, a fantastic web framework for node.js.

Being a web framework, express.js’s function is to help one with handling HTTP requests, presumably as part of one’s site, and at the heart of this function is the concept of routing which is, so to speak, a form of abstraction relating to this handling. Ironically, explaining this in purely abstract terms is difficult, so I shall make do with an example. Assume you’re programming a transport site, and want to add in a map which displays the destinations each of your vehicles are travelling to. Following the principles of MVC, you will also probably want to separate it into the front and backend code. With express, one would just need to call

app.get('/url', function(req, res){  
  // Do stuff
});

Furthermore, these two lines need not even be in the same file, and one can add as many functions to the same address as possible. Of course, when it works for one, it works for many, and this system is expandable for as many addresses and as many functions as one will need, hence the term abstracted.

Now, before I continue further, I must mention that I am more of a C person. That is to say, despite being rather decent in languages such as Python and JavaScript, given the chance to do so without sacrificing function, I would rather do things in C instead. There isn’t much reason to it, other than liking its function, simplicity and portability.

For a couple months now, I have been toying the idea of doing a web framework with some semblance of express, but in C. “Why?” You may ask, well the reasons vary. On one, serious hand, one can say that is it to breath fresh air into the musty world of C web frameworks, giving an alternative, albeit really terrible, to things like kore.io and onion. C offers some advantages over nodejs, namely speed, deliberateness and support. On the other hand, because the former were not the actual reasons for me doing so, it was because there was nothing to do. The KSP console has been mostly put on backburner while the school term goes on and the others work on Sentibots, and as such I have no small project to occupy myself with, especially with this coming short week break. Thus, expressc was conceived.

Now, the heart of a web framework is a web server, as it has to handle the receiving of requests and sending out appropriate responses based on what the user has programmed. While making a web server in C may sound like some daunting challenge involving a few hundred lines of code, in reality a simple web server is very, well, simple, especially since sockets are handled by . A server’s function is to listen on a particular port for any data being sent to it, and to send out data in kind. With sockets, this port-work, so to speak, is simplified, as the system handles when a connection is made, allowing an opportunity for the appropriate code to be executed to handle this event, while in turn providing facility for a response to be sent out. Thus, to program a simple web server, all one needs to do is to parse the request received in said appropriate code, construct a response based on the request and send it out, all of which, in the context of the web, is merely string and maybe a little bit of file processing thanks to the effects in effecting standards by the World Wide Web Consortium. If one wishes to learn more, an excellent article can be found here.

While making something approximating the simplest functions of a web server is interesting, it is only at best the groundwork of a web framework. As mentioned before, the heart of express is its so-called “abstraction” capabilities, and it is these capabilities I seek to approximate in expressc (as a side note, rather imaginative name isn’t it?). Now, C isn’t capable of doing callback functions as one may see in the docs of the proper node.js express, but I feel that function pointers are capable of performing similar function, albeit with their own advantages and disadvantages.
Before I continue, allow me to detract a little into the concept of pointers. When I was first learning C, pointers, along with bit-shifting were spoken of with this almost mythical air of reverence, as if merely introducing them will complicate matters tenfold. I don’t know if this is the case elsewhere, but I think it will be useful to explain nonetheless. Everything in C, from variables to functions, has to exist somewhere, and that somewhere is naturally the memory of the computer. A pointer is simply a representation of that particular thing’s, be it variable or function, place in the computer’s memory. It doesn’t represent the object per se, but merely where the object is. To access the object’s data, or to get a pointer to an object, some symbols, “&” and “*” respectively, have to be appended to the front of the pointer name. In particular, functions are capable of being pointed to, and this pointer, also known as a function pointer, is called, the function, and its contained code, will be run in turn.

This brings us to another question, how is this useful? Why not merely just call the variable directly? Well, in the case of expressc, pointers have a very important use. Since they just contain where an object is, even if the object doesn’t exist yet, it can still be used as if it does. An analogy of this would be how artillery crews are capable of shelling a target based on a spotter’s coordinates even if they themselves cannot see the target directly. This allows expressc to be able to find and run the functions associated with a particular address when a request is sent to that address even though said functions do not exist yet at the time of writing the current iteration of the library. Of course, if the program tries to run a function that does not exist by addressing it through its pointer, it is more often than not going to touch a portion of the computer’s memory that it is not supposed to touch, causing a segmentation fault. Hence, careful care has to be taken to ensure that only functions which exist are referenced. In normal usage, expressc only iterates through, and then calls, the function pointers that are assigned to it with addresses, and since the assignment function is declared to only accept such function pointers, one has to go out of the way to make such an invalid case happen, if it is even possible.

Currently, expressc has two rudimentary ways to send a response back to user. One simply sends a simple message specified by the user, and the other breaks a specified file into chunks to stream over the socket. There isn’t much to talk about either, but they deserve a mention nonetheless.

Now, given that I have quite literally started this project only about a week ago, with only around two afternoons devoted to fleshing it out, there is quite a good bit more to be added and fixed before it can even hope of being on par with the real express.

First of all, data handling. Of course, making a web application is only good if one can actually see and respond to what a user inputs to your program, and being ability to support multiple functions only good if one can access the data between the functions. Addressing the former, while expressc already parses and makes available the headers and body in the request in the form of a struct being passed to the functions the user sets, there is still more to be improved on. Namely, there are occasions in which data is sent as part of the URL, such as a RESTful API request. As of now, the user has to parse the address himself, but I believe that doing the user’s work for him is a trivial task, returning the data through variable argument lists. While the user can pass data between functions through the use of global variables, I feel that this shouldn’t be the case as it complicates matters more than enough, instead, through the use of variable argument lists, I can provide pathways through which users are capable of passing their variables from function to function.

Secondly, adding a templating engine akin to a rudimentary Handlebars. Currently, the only way one can respond to a user’s input is to send different files or messages in response. This clearly is suboptimal as there is a good number of occasions in which one would require to modify data in a page before serving it. A templating system is a good way to address this issue.
Lastly, while what I feel is the heart of express is in place, this is by no means the complete express, with many more features such as static serving needing to be added.

And of course, there is always the slight problem of the current version being utterly incompatible with Windows. Back when Windows was first developed, its creators decided for whatever reason to follow a different standard other than POSIX, meaning that in order to work with sockets on a Windows machine, one has to utilise the winsocks library, which has some minor differences from the sockets library currently used.

All in all, there is still quite a bit more work to do, the quality and purpose of which is all rather dubious, but if you want to try it out, it can be found here.

Thank you for your (wasted) time!