Hi @Dalzhim thank you for taking the initiative to provide websocket support for open-sourced proxygen! It is towards our upcoming goal to extend the open-sourcing of proxygen modules and we should certainly consider the websocket part.

On the other hand if we want to create this support feature available for users right now, can we consider moving it to external?

Thanks,
Lanxi

Hi @lanxi ! I'm glad to hear there are still plans to extend the open-sourcing of proxygen modules such as WebSocket. That would completely deprecate the Websocketpp bridge I have implemented in this PR which isn't as efficient as it should be.

For the time being, moving this feature to external seems very appropriate! Thank you!

I'd like to verify, were you asking me if you can move the new sample app I created to the external directory, or were you asking me to do it? Also I'm guessing it would be preferable if this sample application wasn't part of the binaries that are built when using the instructions out of the box. I think it should be built only when people explicitly want to experiment with it as it requires a third party library (websocketpp).

@afrind has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

Hi @Dalzhim, really happy to find your pull request for websocket. We are currently using proxygen for our server, and going to support websocket, this really help us a lot!

The WebSocketHandler is very simple to use, but I have a question, how can I support HTTP and websocket at the same time for the same port? Since we need to keep the compatibility for the original users.

Thanks.

Hi @kapcino, I'm very happy this pull request was useful to you! Please be aware that there are at least 2 things that should really be improved about it before it is production ready:

1. Search for the single const_cast I used to cheat around a problem I had and find a way to get rid of it
2. Profile real WebSocket sessions to make sure the conversions from Proxygen's folly::IOBuf to Websocketpp's std::string are not a problem for you

Otherwise, the solution I have used to support both HTTP and WebSocket requests on the same port is to instantiate a different RequestHandler based on the GET request. Basically, some of my routes were HTTP only while others were WebSocket only. The RequestHandlerFactory is where I make that choice before I instantiate the appropriate RequestHandler instance.

I wish you good luck. Unfortunately, I have given up on this Proxygen+Websocketpp solution and migrated towards https://github.com/boostorg/beast so I don't plan any further contributions here.

Thank you @Dalzhim I will check the items you mentioned. I am also curious about the reason you abandoned Proxygen solution, could you please share some of the considerations? We checked Boost beast before, and found the interface was low level and not as clean and simple as Proxygen.

@kapcino: I moved away from proxygen for various reasons :

• Build can sometimes be broken for multiple weeks
• Lack of support for macOS
• Lack of direct support for WebSockets
• Large amount of dependencies my project doesn't need otherwise
• Lastly: Facebook, as a company, doesn't seem strongly committed behind this project and I don't see most of my list changing in the near future