Thoughts on web development architecture through integrating C++ in the future to a web application

Question

I'm looking to build a website (it's actually going to be a commercial startup) I saw this question and it really shed some light on a few things that I was hoping to understand (kudos to the op). After seeing that, it would make sense that, unless the website were required to actually have millions of hits per day, it wouldn't be a viable solution to write a C++ backend on the server side.

But this got me thinking.

what if it in the (unlikely) events of the future, it does go that route? The problem is that, while I'm thinking of starting this all using .Net (in the beginning) just to get something quick and easy up without a lot of hassle (in terms of learning), and then moving towards something more Open Source (such as Python/Django or RoR) later to save money and to support OSS, I'm wondering IFF the website actually becomes big, will it be a good idea to integrate a C++ backend, and use Python ontop of C++ for a strong foundation, and then mitigate HTML/CSS/AJAX/etc ontop of the backend's foundation? I guess, what I'd like to know is that, given the circumstance, if this were to happen, would it be a proper approach in terms of architecture? I'd definitely be supporting MVC as that seems to be a great way to implement a website.

All in all, would one consider this rational, or are there other alternatives? I like .Net, and I'd like to use it in the beginning, because I have much more experience with that than, say, Python or PHP, and I prefer it in general, but I really do want to support OSS in the future. I suppose the sentence I'm looking for is, "is this pragmatic?"

Answer 1

No, because it's more effective to scale horizontally than vertically

Meaning, it's better to design an architecture where you can spread requests across a number of less powerful machines; as opposed to, building one super powerful machine running code that has been optimized at a lower level.

The drive behind horizontal scaling is due to the 'nature' of the web. Websites are very IO heavy not compute heavy. There are exceptions, such as YouTube where they're encoding massive amounts of data but that can be dealt with by setting up compute nodes and an effective task management system.

For instance, You could implement a reverse-proxy server that does nothing but distributes incoming requests to other servers to fetch content. It doesn't matter where the data is returned from as long as there is a common origin for requests (and even that can be extended using advanced DNS).

At the very minimum, it's common to split the 'data layer' (ex database) from the 'web layer' (http server). Even StackOverflow has a clear separation between the two by implementing C# on the 'web layer' and a separate REST API (also C#?) to access the database.

Even when you need to tap into the raw computing power of C, many 'glue languages' like python have the built-in capability to implement C/C++ extensions.

There are a lot of ground-breaking being made in the field of scalability and fortunately, the people who are breaking new ground like to share the specifics their approach.

Basically, it comes down to:

Architecture trumps raw computing power when it comes to the web

HighScalibility.com is my favorite site to read about scalable architecture development but there are plenty more to be found on the web.

---

Aside:

One of the greatest bottlenecks to handling web requests is the architecture of the HTTP server. Traditional servers like Apache fork a sub-process for every request. It works but every sub-process that's added to the stack needs it's own pool of memory and will inevitably increase the overall task-switching overhead on the server.

A DDOS attack is directed to take advantage of this weakness by overloading the HTTP server to the point where it can't physically handle the load any longer and crashes.

Multi-threading has been introduced as a stopgap measure but writing 'good' multi-threaded software is hard to write and multi-threaded bugs are notoriously hard to pinpoint.

Another 'school of thought' that has become popular recently is event-driven webservers like Node.js and nginx. They rely on a simpler single-threaded model and a programming style that mitigates waiting on a function returns by implementing a fire-and-forget model. It's more difficult to program in such a manner but as long as heavy compute tasks are passed on to servers specialized for it, the numbers (ie hits/sec) they can handle (on even commodity hardware) are impressive.

Answer 2

You might as well ask Facebook, they had the same issue you do - they started with PHP thinking they could do a site quickly and easily, but when it got big they had to do something to manage the scalability problems.

If you learn from their example, you should go straight to the C++ version from day 1 and save yourself the hassle of rewriting it all. However, that assumes you will need to, many sites work acceptably with perl or PHP code.

Writing web code is quite straightforward, you only need to grab the request, process it and generate some HTML code to return. The frameworks that other languages provide just make manipulating the standard XML (but don't forget JSON) and HTTP protocol bits easier - and there are several C++ frameworks or libraries that give you these features, so the problem just becomes one of integrating them into your code.

The best thing you can do is to split your code away from the webserver, when I worked for a company that had a very large website-based system, we wrote all our business logic code in services that ran on application servers, the web server and associated code was pretty much there to server static data (images and css) and to pass the requests to the services. This let us scale tremendously. IMHO webservers should be considered part of the presentation layer, not somewhere to stick your business logic. This especially applies if you need stronger security as webservers are notoriously bad at being un-hackable.

Answer 3

Stackoverflow itself is a pure C#/.net site and it doesn't seem to do too badly.

While facebook may have decided to re-write some critical parts in C++ after it made its first billion. Had they started out writing in C++ I think don't think they would have got that first billion.

The LAMP stack (and .NET) allows you to develop stuff quickly, which gives you the freedom to try out new ideas, and, to quikly discard old ideas that didnt quite work out.

The whole point of facebook was the user experience. While you are messing about with memory allocations for string classes you will not be thinking about appearence and usability.

Answer 4

Update: also check this question: Are C and/or C++ viable/practical options for web development?

I think it is pragmatic to use C++ for projects that will have an impact on both energy and necessary infrastructure necessary, as it might reduce both a lot (check for Hip Hop from Faccebook:http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/ they reduced their server use by half just by converting PHP to C++).

I think it depends on your main bottleneck for the project: is it developer productivity OR application efficiency? If it's the second then you can use C++, as suggested by CPPCMS:

When CppCMS Should Be Used.

C++ language is far from being popular for Web development for many reasons: lack of appropriate tools, skills of developers and many more.

However, there are areas where C++ web programming with CppCMS becomes very useful and efficient, and some where it is just a waste of time.

When CppCMS should or can be used?

High load web sites and application with hundreds and thousands hits per second, where high performance, efficiency and scalability is required. Application that require scalable Comet/Server Push(1) technologies --- CppCMS can efficiently handle hundreds and thousands simultaneous HTTP connection with minimal resources usage. Embedding web interface(2) into existing C++ applications/services with a small cost of additional library. Embedded underpowered devices -- CppCMS allows creation of rich applications with relatively low cost of hardware that would perform reasonably fast. When Not To Use?

If you create small web applications that do not require high loads and require very short time-to-market period -- probably tools like Django or RoR would be more appropriate for such tasks.

(1) Available in upcoming CppCMS 1.x. (2) Current version of CppCMS (0.0.x) can be used for embedding web interface to existing applications, but the next version 1.x would support it much better.

If C++ (or like) language were used for all websites, internet would be faster, more responsive, lower cost on energy and memory. But realistically, not all web project have efficiency as the main bottleneck to prioritize the work on. That said, it might help our planet to heat less if we tried to go this way...

Answer 5

I don't think so.

C++ will always have its place in OS and driver development, but as far as web applications go, the bottleneck is rarely the server running it; it's all in the network bandwidth and the time it takes for a client machine to see updated information.

Servers have come a long way, and are quite capable of running garbage languages [I won't point any fingers; you know who you are] without a client even noticing the performance hit.

PHP seems to be where it's at for many web applications, and with some of the new capabilities of the modern web and modern computers, it's also becoming more and more common to push more of the processing on to the client machine (as opposed to letting the server manage it all).

You very well may find a use for C++ on the server, though it may be simpler to just make a CGI script in a more modern, easier to code language.