It’s not often I discover a new framework or technology and get immediately excited about it. Often that’s because the technology in question will either seem to me to be a solution to something I don’t perceive to be a problem in the first place, or because in addressing one problem, the technology introduces a new set of concepts or abstractions that make the overall task of solving the problem even bigger than it was in the first place. More usually, it’s because the framework or technology focuses on just one area of the overall problem, and doesn’t fully address the bigger picture adequately.
There are three key technologies in the Facebook stack:
- React (and its mobile variant React Native)
React is a front-end framework, designed around the principle of creating re-usable components and building applications as a hierarchical tree of such components with a one-way flow of data down through this hierarchy.
GraphQL is a standard for specifying data queries. The interesting part of GraphQL is that it is independent of the actual database or language – it can be ported to any database and how individual database queries are technically implemented is up to the developer and independent of GraphQL itself. GraphQL doesn’t mandate the transport protocol either – it can be implemented over HTTP or WebSockets for example. In Facebook’s own words: “application servers take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes”.
Relay sort of sits between React and GraphQL, providing a largely automated set of abstractions that allow the front-end application developer to forget about the technicalities of how data required by an individual React component is fetched and made available to it.
Interestingly, whist the three technologies have been designed to work together, at least the first two – React and GraphQL – can be used independently. So you can quite happily develop applications that just use the React framework without using GraphQL, and conversely you can use GraphQL with any other framework and, generally, as an alternative to other means of database querying and data fetching for whatever purpose (ie not specifically related to front-end application development).
Rather than describe these technologies in detail in this article, it’s better for you to get that information straight from the horse’s mouth: Facebook have published a lot of information already which you can find by using Google. However they delivered some astoundingly good presentations at this year’s ReactEurope Conference. For the fastest and best introduction to these technologies, I’d strongly urge you to watch the following, in the order below:
My interest, of course, revolves around the EWD.js technology and its ability to breathe new life into legacy systems that have been built using the Caché and Mumps technologies. Health IT is one of the major users of these technologies. As I watched those Facebook videos and delved more deeply into the details of their technologies, I couldn’t help but relate the issues, case studies and examples the respective speakers talked about to the equivalent issues, challenges and problems that surround the modernisation of those legacy healthcare applications. Additionally, the more I thought about GraphQL, the more I could see the parallels with the challenges involved in facilitating the interchange of patient data between those applications. It came as an interesting surprise to discover just a couple of days ago, that, on that latter front, Josh Mandel has been thinking along the same lines, with respect to how HL7 FHIR could be mapped to GraphQL queries. I think GraphQL could have a key role in the next generation of SMART App development. I can also see parallels with the work of Conor Dowling and his work on FMQL: by definition, GraphQL is all about visualising and querying data as graphs.
The key thing to understand about GraphQL, and why I believe it’s so important, is that the technical details of how each query is actually implemented is up to the GraphQL developer of that query. In the case of the Open Source, Mumps-based Electronic Healthcare Record (EHR) called VistA, for example, I can envisage how GraphQL queries could be physically implemented around the already existing VistA RPC APIs or combinations of them. This makes GraphQL a very practical technical solution to problems for which solutions have been sought for a long time. For example, I see parallels with the US Dept of Veteran’s Affairs’ (VA) VistA Service Assembler (VSA) project (see the slides available via this link). One of its aims has been to remove the low-level granularity and “chattiness” of traditional REST-based SOA solutions – an issue that, as made clear in those videos, has also been recognised by Facebook and for which GraphQL has been specifically designed to address. A further intriguing prospect is whether and how GraphQL Schemas could be generated from the metadata held in VistA’s FileMan data dictionary.
In conclusion, I want to congratulate the amazing development team at Facebook on their ground-breaking work, and thank them for making the fruits of their deep analysis and experience available to the rest of us through Open Source. I believe their impact can be profound within the Health IT world, which is in desperate need of excellent technical solutions to its many problems. I’m hoping that my efforts of making their technology stack available through EWD.js can provide a catalyst for that to become a reality.