Facebook Gets it Right, and We Can All Benefit

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.

In recent months I’ve been watching more and more closely the work of Facebook.  They’re an interesting company because they’ve had a serious need to create and maintain large teams of developers who work on all the different versions of their application across the full range of modern desktop and mobile devices.  On mobile devices, in particular, they’re faced with maintaining support for numerous old versions of their software, whilst pushing out new enhancements and releases onto existing and new mobile devices.  Needless to say, they have some of the world’s best JavaScript developers at their disposal and, I suspect, a respectable development budget.  Nevertheless, over the past few years, they’ve been doing some careful analysis of how to create a scalable approach to development that maximises code re-use across all platforms, avoids re-invention of wheels and maximises the speed and quality of their application development – basically the kind of stuff to which everyone in IT can relate, right? In doing so they’ve looked at all the angles: the front-end, back-end, and, importantly, requesting and accessing data from the database server(s) and consuming it on the front-end.  They’ve carefully and intelligently analysed the inter-relationship between the front-end and back-end developer and, crucially, how the nature and process of data fetching affects and dictates the collaboration across the front and back-end teams.  What they’ve created is a set of technologies that are, in my opinion, truly ground-breaking.  Even more interestingly, they’ve made the fruits of their efforts available for the rest of us – they’ve released all their technologies as Open Source products.

There are three key technologies in the Facebook stack:

  • React (and its mobile variant React Native)
  • GraphQL
  • Relay

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.

So I decided that it was imperative for these Facebook technologies to be supported by EWD.js.  In fact, React and React Native have been supported for some time: I recently published a video showing a demonstration example of the Open Source VistA EHR being accessed via a React Native application running on an iPhone.  However, GraphQL and Relay support required some additional effort, but, to coincide with publication of this article, I’ve pushed out a new build of EWD.js that supports the entire Facebook technology stack by integrating their JavaScript reference implementations.  This means that  these important Facebook technologies can now be applied to any Cache or Mumps-based application, including non-healthcare ones.  EWD.js makes it very simple and straightforward to use GraphQL, and queries can be transported over HTTP, REST or WebSockets, right out of the box.  I’ve begun to publish technical information in the EWD Google Group forum to coincide with the publication of this blog posting.

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.

Advertisements

5 comments

  1. Thanks for taking the time to raise awareness of these practical innovations; and for providing links to more details.

  2. A useful link for anyone interested in the GraphQL specification – see their JavaScript reference implementation at https://github.com/facebook/graphql

    EWD.js makes use of this – see https://groups.google.com/forum/#!topic/enterprise-web-developer-community/okC6T2W-Sfk

  3. Wow! I have REALLLY enjoyed and benefitted from reading this blog and the listed resources over the last several days. I’ll probably be getting a Mac in teh next week or two to delve into React Native – Relay (with GraphQL).

    In the interest of multi-platform until they release an Android, have you had any experience with Tabris.js? And, if so, do you think it could be GraphQL friendly?

    http://eclipsesource.com/blogs/2015/09/02/tabris-js-1-2-is-here/

  4. I’ve not looked at Tabris. My approach is to be patient and await React Native for Android. They’ve promised it, they’re already using it at Facebook, so it’s just a matter of time. Meanwhile familiarise yourself with it by trying out the iOS version and, of course, React.js

  5. Reblogged this on Jibrel and commented:
    Must read

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: