Async

[GuacheSuede]

Hi Thomas, is there async/multithreading support ?

[daedric]

Hi,
The server and client are already async and support multithreading.
Can you elaborate on what you need ? :)

[GuacheSuede]

@daedric Hi Thomas, I am trying to write an API server serving JSON. What do you suggest ?

[daedric]

Several API endpoint have been implemented using HTTPP already.
The server will handle the request for you and call the function you defined. You can take a look at some of the examples:

• Small (not so featured) helper to dispatch request depending on the endpoint: https://github.com/daedric/httpp/blob/master/examples/rest/rest.cpp
• Shortest amount of code to get a server running: https://github.com/daedric/httpp/blob/master/examples/ping/ping.cpp

The connection you get in the callback can be kept as long as you decide. HTTPP does not put any constraints on when you have to answer.
For instance this library is used in some RTB project where we keep the connection for about 200msec waiting for an answer or we send back a 204.

Do not hesitate if you have more questions :)

[GuacheSuede]

Thank you Thomas, great help, got it now :)

[GuacheSuede]

@daedric Thomas, dont mind me asking where do you use this in your work and what for ?

[daedric]

Not at all,
So as previously said it is used as a RTB gateway. It receives a decent amount of traffic that gets normalized and sent to a backend that will compute an answer. If the answer does not come before the timeout, a standard answer is sent (204).
It is also used as internal REST service with low traffic. In this case C++ is overkill but in the project using HTTPP the code was able to reuse some existing C++ code avoiding a code duplication.
And more recently it is used at my previous job as a gateway once again, very similar to the RTB use case but without the need to wait for an answer from the backend.
It is production ready and proven very stable and efficient. Compared to some of the alternatives (which were not existing at the time the first version was written) it is also much smaller.

It is worth mentioning that HTTPP is to be behind a nginx or some other full featured and more secure server or only open to some trusted network.

[GuacheSuede]

Thanks for the reply Thomas, would you happen to have an example for the nginx proxy to server ? Also have you considered plugging an lwan backend ?

[daedric]

About nginx look up upstream block and the proxy_pass statement.
About lwan yes, it was a strong possibility but it had and has too many features we did not need (mime, files, compression, etc.) and more; therefor, HTTPP core is about half of lwan's.
It was also not advertised as something stable in 2013.

Long story short, HTTPP aims as being as simple as possible, if you want to serve files this is certainly not the library to use.

[GuacheSuede]

Great !, Thank You Thomas for the nginx refrence.

[GuacheSuede]

@daedric Good News Thomas, I have decided to use this Library !

[daedric]

I'm really glad to ear it.
Do not hesitate to create issues if you need help with anything

cheers