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.
Comments