Although it's only a few years old, GraphQL has already generated tremendous excitement among tech firms, startups and developers alike. GraphQL was initially created and released at Facebook in 2012, where it was used in the company's native iOS application. Three years later, GraphQL was officially announced to the public and open sourced at the ReactEurope conference. In September 2016, it finally became production-ready, with new documentation and support from GitHub for use with its public API.
As more and more companies experiment with and embrace GraphQL, it is easier than ever to try it out for yourself. With so many tools and resources available, you can benefit from the experience and knowledge of those in the community who have already adopted and contributed to GraphQL. Here are a few things that you need to be aware of before starting on your GraphQL journey, and a few examples that you can build on for your own projects.
Traditional constructions such as the database schema, with its manifold boxes and arrows, are not always relevant to software development today. Front-end developers no longer directly interact with a database, but rather via an API that might not share the same fields. In addition, not all of the fields may be in the same database; they may be dispersed throughout MongoDB and various APIs.
Companies using GraphQL often choose to adopt what's known as the GraphQL-First development workflow. As the name implies, GraphQL-First means that your application's GraphQL schema, which is language- and technology-agnostic, should be your first point of consideration during development. The schema serves as the meeting point for, and the unifying link between, your front end and your back end.
The essential steps of GraphQL First development can be enumerated as follows:
GraphQL made it possible to combine data from MongoDB and DynamoDB within a single request, which resulted in a significant performance upgrade. In addition, the change made it much easier to simplify the front-end Galaxy code.
Optics is a performance monitoring tool for GraphQL developed by Meteor that, unlike Galaxy, was designed from the outset to work with GraphQL. As such, developing Optics involved a lot of premeditated thought about the nature and structure of the application's GraphQL schema.
The first question faced by the Optics development team was one about the ultimate ownership of the schema: did it rest with the back-end developers or the front-end developers? This conflict illustrates the varying goals that the two teams have; back-end developers want to remain open to the possibility of different applications and features, while front-end developers are inclined toward specificity and efficiency. In the end, the schema was designed to be somewhere in the middle of these two extremes, although slightly favoring the front end.
GraphQL's abstraction layer enabled the Optics team to decouple the development of the application's various parts, and to use component-first development throughout the project. Each component was built one at a time, tested using data mocked from open-source tools, and gradually integrated into the final product. As a result, the Optics back end and front end were able to be connected in less than two days after being developed separately for weeks, and the entire application was production-ready after less than three months of development.
A number of open-source tools developed by Meteor are available to ease your transition into GraphQL. Three of the most popular and useful are described below: