As a full-stack engineer with a bias towards the database...and a career spent working with and evangelizing database and distributed systems...why GraphQL? In this talk, I will share some of my personal journey with React, GraphQL, their respective communities, and my point-of-view on the future.
GraphQL and React - Two Great Tastes that Taste Great Together
AI Generated Video Summary
2. React and GraphQL Benefits
Hey, I'm Adrian, and I'm going to talk to you about React and GraphQL. I'll share two stories of my own that highlight the benefits of using these technologies. The first story is about an IoT devices project where we needed to replace a native Windows app with a web interface. The second story involves a reporting interfaces project with various data sources and databases. By using React and GraphQL, we found that we had access to effective software development patterns, improved data fetching, and better utilization of mutators and accessors. We also benefited from the familiarity of existing development staff with patterns like data transfer object and data access object. Additionally, GraphQL allowed us to avoid lock-in and achieve component reuse, while React and GraphQL seamlessly integrated with modern development paradigms like Reactive and event-based programming.
Hey, I'm Adrian, and I'm going to talk to you about 2 great tastes that go great together. Like eggs and bacon for breakfast, or rice with a nice fried egg, and other delicious ingredients in bim-bim-bap, or naan and curry. Great things, great tastes, all match together.
In this situation, though, I'm talking about React and GraphQL, and I'm going to tell you about two stories of my own that are basic anecdotes of what I went through to make the argument for React and GraphQL to be used on projects. Specifically, an IoT devices project, little RFID chips were being used inside of massive warehouses and across geographic areas to track e-commerce products and things like that, and also just containers of things within an overall warehouse and their movement in and out of a place. We needed an interface to be built that would replace a Windows app. It was a native Windows app. I believe it ran on Windows 95, Windows 98. So a little on the older side these days, but we wanted to bring it to the web so that people could use it not just on a Windows desktop, but out on the web anywhere.
And then the other project is a reporting interfaces project where we had all these disparate data sources and different databases like Postgres and MySQL, Apache Cassandra, and other things. Some of the databases were even so distinctive and kind of old that they were like multivalue databases. Who's heard of that? It's not even a used thing anymore. But one database was 30-something years old, and we got a GraphQL interface over that and used it in this project.
So, why React and GraphQL? Why did I push for that on these projects? The key thing is this basic list that I'm going to give you. It started out with just mentioning the patterns and practices that we got kind of out of the box with both of these libraries. With React and GraphQL, there's a lot of pieces that are used that just immediately use patterns that are very effective for software development. Then beyond that, as with patterns, we got a lot of repeatability and reuse out of those pieces within those libraries. But it also helped us to expand past that and avoid a lot of overfetching or underfetching of data. That's one of the great benefits of GraphQL. It really helps you kind of hone in on what you're trying to get and work with your data. And then beyond that, we also kind of honed in even more on the way we use mutators, accessors, and all of these things to get that data and what we were doing with that data. It helped a lot. Then we used a lot of patterns like data transfer object and data access object that a lot of the existing development staff already were familiar with. They weren't quite always familiar with, say, GraphQL or maybe React, but they were able to ramp up really quickly because of the existing familiarity with patterns they had used in the past. Then moving on beyond that, we got rid of a lot of the what-ifs, such as, what if we are going to use this database forever and we're going to shift it to this other database? Are we tied to it? Do we have lock-in? Well, GraphQL just knocked that right out of the door. We're not locked into anything because we're building a tier over the database. And then we get a lot of component reuse and things like that where it's more easy to follow things like that single responsibility pattern for the React components. And then, moving even further, a lot of those modern development paradigms around Reactive and event-based programming are easy to use with GraphQL and React, because a lot of it is the native way those libraries would do something, being that they're both built focused around the asynchronous web. So, just the inherent nature of the way they work makes that even more possible and easier to implement with Reactive. So, kind of bringing all that back around, that laundry list of things back around, and doing a little back-of-the-napkin math, as one might say.
3. Benefits of React and GraphQL
I've built 40-plus enterprise applications and was able to make the argument for using React and GraphQL for two specific projects. By using these libraries, we achieved better overall code maintenance and design acumen. Building teams of passionate individuals interested in React and GraphQL solidified the argument for using these libraries. Additionally, React and GraphQL reduced the Not Invented Here syndrome and allowed us to implement patterns that increased code reuse and reliability. We were able to ramp up new team members quickly by providing existing reference materials and community-based resources.
I've built 40-plus enterprise applications. And that was just two that, specifically, I was able to make the argument for and get React and GraphQL used for those specific projects. And in my experience, from those other enterprise applications being developed, and us going with React and GraphQL to develop those two specific applications, which were very different, very different applications, we got better overall code maintenance. We got better design and pattern use acumen across the projects.
And a lot of that had to do specifically with using those libraries. And it was also because we had great teams. And as I mentioned here on this slide, in the strategic advantage section, one of the big things was that we were able to build teams of people that were really passionate and interested in using this technology specifically. They were interested in React and they were interested in GraphQL. So building a team with people that were very interested in using the tech and interested in doing things within a domain with that tech really helped to kind of just firm up the argument to use these libraries.
And then finally the tactical things were really just the icing on the cake. Being able to get rid of the situation where developers routinely felt like they needed to reinvent something because pieces just weren't there. But with this, with React and GraphQL, it dramatically reduced the NIH or Not Invented Here syndrome. And then, also, beyond just having those existing patterns being put into place and being available that are used in React and GraphQL libraries, we were able to implement patterns over that that increased reuse, reliability, consistency of the code base, and getting people ramped up as we brought people onto the teams. We were able to get them ramped up more easily by providing reference material that already exists and community-based material that already exists to get them up to speed. And that helped the existing team members keep moving on the project and at the same time ramp up new people to start contributing almost immediately, at least, in some cases, within hours of being brought on board.
So that is two of the projects. And the TLDR of that is using React and GraphQL. Position a project ahead of the timeline. Put you in a very good position. Thanks for giving my talk a listen. I'm Adrian. You can find me at GitHub or Twitter as Adrian. I enjoy the privilege to work with the awesome Hasura team building, supporting, and advocating for the amazing GraphQL engine. And we are hosting a GraphQL conference where we are inviting senior engineers and leaders from Fortune 500 companies to learn how to use GraphQL to help them build apps faster. Learn how to use GraphQL. Come join us. Sign up and register at Enterprise GraphQL. There's the Bitly link. I'm Adrian. Thanks for listening.