Hey, GraphQL Galaxy. In this Lightning Talk, I want to take you through what it took to set up GraphQL subscriptions for an existing Drupal-based product. I'm Alexander Farweg or Kingdutch on places like Twitter and GitHub, and I'm the Lead Frontend Engineer and GraphQL Initiative Lead at OpenSocial.
OpenSocial is a community engagement platform that helps organizations connect with their communities online and grow them in the process. OpenSocial is built on top of the Drupal content management framework. To allow quicker communication between members on our platforms, we wanted to use GraphQL to add a real-time chat as a new feature to our existing products. The goal was for the chat to integrate with our existing member and group structure. To build our chats, we chose Rescript and React. And of course, GraphQL to let our server and client communicate. On the client side, we chose the excellent Urql GraphQL client.
In PHP, there are a few libraries that can help you with GraphQL. The best choice in my opinion, and the one used in Drupal, is the GraphQL PHP library. This is a PHP port of the JavaScript reference implementation. I'm a big fan of the library structure. It makes porting new GraphQL features to PHP very easy. For example, one of my first contributions was implementing interfaces extending other interfaces. To achieve this, I could almost copy and paste the JavaScript tests and implementation word-for-word.
Just replacing a bit of the syntax. Drupal itself works with modules that allow you to create a site by bundling together functionality. The Drupal community has provided an excellent Drupal module that utilizes GraphQL-PHP and lets developers easily expose Drupal's data storage as a GraphQL API. As you would expect, queries and mutations work out of the box. The GraphQL-PHP library also supports subscriptions, and the Drupal-GraphQL module does not impose any limitations on defining subscriptions in your schema or resolving them. However, when trying to make GraphQL subscriptions in a framework such as Drupal, we run into some of its limitations. Drupal, like other popular PHP content management systems, such as WordPress, handle individual requests through a web server like Apache or Nginx. This means that once a response to a request is generated, the connection is closed and the memory is cleared for the next request. This short-lived model doesn't work for subscriptions which require a persistent connection and the ability to send data to the client without the client requesting it. This means we need additional service to sit between our client and our web server to handle these persistent connections. We can write these servers in many different languages, such as JavaScript, Rescript, OCaml, Rust or your other favorite language. However, since I was working with an existing team and product, it was important to look at the skills that were already present in our organization. I had to make sure that whatever was built would also be maintainable by others.
Comments