6 ms·
You could make one hell of a good C++ web framework with this. http::controller mypage { //Browsing to http://server/mypage/test?some_str=blah¶m=5
by Negitivefrags 9y ago
You could make one hell of a good C++ web framework with this.
http::controller mypage
{
//Browsing to http://server/mypage/test?some_str=blah¶m=5 calls this
http::response test( const std::string& some_str, const unsigned param )
{
return web::response{ 200, "You did awesome stuff" };
}
//This method can only be called with HTTP POST
[[POST]] http::response save_some_data( const std::string& blah )
{
return 200;
}
};
int main()
{
http::server server( "localhost", 80 );
server.add_route( "mypage", std::make_unique< mypage >() );
server.run();
}
It's all the magic of a modern web framework but in a fast language.
Due to web assembly you can easily have your server and client side scripting be done in the same language, with the same libraries which is also huge bonus.
I honestly can't think of a better stack.
- wocram 9y agohttps://rocket.rs/ https://rocket.rs/ is basically this, but in rust instead.
- skocznymroczny 9y agohttps://vibed.org/ https://vibed.org/ is basically this, but in D instead
- Dzugaru 9y agoASP.Net MVC is basically this, but much more mature and feature packed :) And C# is no slower than D.
- deleted 9y ago[deleted]
- izym 9y ago> And C# is no slower than D. I very much doubt that. Do you have anything to back up that statement?
- Dzugaru 9y agoBenchmarks are tricky and hard to find for dlang as its not that popular, but I have common sense to back that statement. Dlang garbage collector is really really slow for now [0], and C# has a very fast GC and overall is almost as fast as zero-overhead languages like Rust or C++ [1]. So, its reasonable that for anything that involves GC (we all can agree that web server does) D is not that fast as manual memory management languages yet. [0] https://olshansky.me//gc/runtime/dlang/2017/06/14/inside-d-gc.html https://olshansky.me//gc/runtime/dlang/2017/06/14/inside-d-g... [1] http://benchmarksgame.alioth.debian.org/u64q/binarytrees.html http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...
- lossolo 9y agoI have benchmarked D code against C,Rust and C++, most of the time D code is faster than Rust and C++ so I doubt it's on pair with C#.
- kitd 9y agoAlso in Vibed, Diet templates (~= Mustache templates) are compiled using this into binary classes.
- p0nce 9y agoThe new WebConfig library looks promising too: https://github.com/WebFreak001/WebConfig https://github.com/WebFreak001/WebConfig
- stepik777 9y agoProponents of C++ for some reason think that C++ is the only fast language while all others are slow interpreted scripting languages.
- pjmlp 9y agoOnly those that never used other languages besides C.
- kllrnohj 9y agoIt's more that C++ is the only widely adopted fast language. Rust and D are the only real challengers there but D doesn't seem to have caught on and Rust's growth, while impressive, isn't up to widely-adopted language status yet. Granted most things don't /need/ the raw throughput potential of C++, but if parts of your code really does need it then it tends to be easier to just make the whole thing in C++ than deal with bindings to other languages.
- EGreg 9y agoSorry but can someone explain why C++ by itself can't be good enough for a web framework? OKCupid wrote one back in the day. ALSO: Your example is much slower than the same server written in Node.js, haha. Because the language doesn't support evented programming. The language may be fast, but the paradigm of blocking while waiting for I/O is slow!
- pjc50 9y agoAhem. Back in 2001 I was working on what was at the time the fastest webserver in the world: Zeus. It was written in C++ and built around select(), which gave it effectively evented programming. One process per core. Primarily for serving static content, although there was a fastcgi interface and, god help you, IBM Websphere integration. There were a few quirks to the codebase. No STL; instead our own containers and length-based string classes. There was also a "stringrange" type class, which referred to a range of a longer string. So it parsed in the entire HTTP header as an octet array, then created objects to refer to individual headers. Since the input header was immutable this worked beautifully. Considerable effort was put into avoiding unnecessary copies. It also had at least a dozen target platforms; Linux, SunOS, IRIX, and architectures from ARM to Itanium. I'm not sure on how many of those we ever sold a license.
- EGreg 9y agoI remember that server! It's really cool stuff, and select() can definitely be used in C++. But there is no real evented ecosystem for mysql, pgsql, websockets, and all the other types of I/O unless it is all done through sockets. I think all languages can do an event loop, it's just a question of the ecosystem. Javascript is designed around async and Node.js was heavily promoting it from the beginning. So the default pattern is async. That's what I meant. Yes, sure you can do the web server and even middleware as async, but there are many services (redis, memcached etc.) and having async modules for them all is the key.
- simias 9y agoCGI scripts used to be fairly popular back in the day, it was not uncommon to have C or C++ code facing the web directly. The main problem is that web apps have a huge surface of attack, a huge part of any web application is handling untrusted user input. For this reason you're taking significant risks by using a memory-unsafe language. Also web services are rarely CPU-bound, so the added performance matters less.
- buie8 9y agoYou can do exactly this with the Haskell "servant" framework. Works great. It's in fact even more powerful than this. Your routes are first class, so you can pass them around and generate type-safe links. It also doesn't require any "meta" level programming, just plain Haskell. And Haskell is blazing fast, not far behind C++ (especially when using high level C++ APIs like std::string) https://haskell-servant.github.io/ https://haskell-servant.github.io/