When humans decided to try and land on the moon, they had to invent a lot of the technology for the project from scratch. It was hard, expensive, time-consuming work with lots of wrong turns and dead ends. That's what it's like when you're using systems no one has experience with. There are no veterans around to answer your questions when you get stuck.
I'm Cassidy Williams, and I've been working as part of the team at CodePen. Recently we decided to switch our stack over to use Apollo and GraphQL on top of our React code, which has been an awesome learning experience. I personally love how we can organize our components very modularly, unlike the way we organized it with Redux. But, because Apollo is a relatively new technology, there have definitely been some pros and cons as the team adopts it and learns as it grows.
When I was first searching for answers to issues I had with Apollo, there wasn’t much out there. When you decide to invest in a relatively young technology, it’s harder to find support, even for simple problems. That forces you to look under the hood for yourself, which can be a great way to learn. It also means you get to help build and shape the nascent community and reap the rewards when others begin to see value in the tools you’ve helped to sharpen. For those who don’t know what Apollo is, it’s a single query system to help you run GraphQL at scale in your projects. It establishes a data graph for you to have all of your microservices and clients speak to each other in the exact same way.
It’s kind of hard to explain with just words, so let's talk through an example. In CodePen’s front-end, in a given component we might want to have data about the current logged-in user. Previously, if we wanted that information, we had to set up either some sort of middleware to handle the calls, or call actions somewhere, or just stick an API call in componentDidMount, and then make sure we make separate calls for all of the different data elements we need. At the very least, we would need to talk to the back-end team to make sure that we get the data in the format that we want. With Apollo, at the top of a component, we can plop this little nugget in here, and it will return the current logged-in user, their ID, and whether or not they’re a CodePen Pro user. The code looks like this:
const SESSION_USER = gql`
query CreateSessionUser {
sessionUser {
id
pro
}
}`;Now, let’s say I actually need more data than that, and I need to also get their avatar and their username. Instead of making another query, or contacting the backend team to get that information added to the API endpoint, I can just modify my query:
const SESSION_USER = gql`
query CreateSessionUser {
sessionUser {
id
pro
avatar
username
}
}`;And voila, I have my data! That’s the power of having a single data graph. If the data is in the graph, you can query for it, and the front end is empowered to take and use that data however you want. Now, this isn’t meant to be a sales pitch for Apollo. Apollo is awesome, but it’s also new and still getting a foothold in the dev community. Normally, when something new comes out, it’s very fresh and exciting, and if it introduces new concepts for us to work with as developers, it’s a fun new world we get to play with. At least, until we run into a problem with it. One of the things that I have run into a lot with Apollo is that its error messages leave much to be desired. They have rather generic messages sent to you, so it can be kind of tough to debug if you’re not familiar with it. So, one day I went over to good ol’ Stack Overflow to try and figure out what was wrong with my component. And, to my shock... there were no answers there. There weren’t even many questions on the topic at all! Usually, when I ask something on Stack Overflow, I can get a good number of answers within an hour or so. I waited for weeks but got no response. Because I didn't have an answer readily available, I had to look under the hood and actually get familiar with the code that makes Apollo work. Again, it was a trade-off. It took a lot of time, effort, and frustration. But doing it this way taught me a lot. It also helped to demystify the black box that someone else built, to give me the confidence that I could come to understand this tool as well as the creator, no matter how brilliant they seemed from a distance. My Apollo question got a few comments, but didn’t actually get answers for over a month. I ended up answering it myself after several coworkers and I pored over the issue. Isn’t it funny how you can tell how new or popular a framework is by the number of people who have had problems with it? Vue.js has about 38.5k questions on Stack Overflow right now. React has over 150k of them. Apollo? As of writing this post, less than 5,000 and about a third of those questions are from the past 6 months! It’s good to see that Apollo is picking up speed in the developer community. Just based on Stack Overflow questions, GitHub Issues and even Twitter threads, you can see that people are getting excited, and sharing what they have trouble with and what they’ve learned. My action item to you, developer: when you start using a brand new, shiny technology, talk about it! Ask questions, write blog posts, share on social media, and be open about your findings. You never know who you could be helping! And the more you share, the easier it will be for other people to find you and return the favor.