GraphQL Academy — How Reaktor has allowed me to go from a junior developer to a specialist and instructor

August 3, 2022

Read time 7 min

Working at a tech company with hundreds of engineers and programmers, you get a wide range of experience and skill sets. That’s true of a place like Reaktor, which brings in top talent from around the world who are, for the most part, senior developers. But in an ever-evolving industry like technology, there’s simply no way that each person can master all the tools, programs, and languages out there. So every now and then, a Reaktorian is bound to come across a project that requires them to develop a skill further or learn something entirely new.

That’s what I saw when I joined Reaktor in 2021. I was put on a team tasked with developing a social media app for a retail client. By the time I arrived, we were past the first stages for the project, meaning the basics were already determined—including the API architecture. Because it was a mobile app and we knew network bandwidth and latency would be critical, GraphQL was selected as the best way for our API to flexibly handle the data. That way, we could build whatever the client needed. This was exciting news for me. I had worked with GraphQL in the past and I found it to be efficient and powerful. The problem was, the other four developers on my team weren’t very familiar with it.

Laura stating


Up until this point in my career (which admittedly was not very long), I hadn’t encountered an experience quite like this. At the time, I was 19 years old, the youngest not only on the team but ever to be hired at the Reaktor Amsterdam office. My personality isn’t the type to waltz in and show people what I know while explaining what a genius I am. In truth, I suffered from imposter syndrome and I was very insecure. I thought about just putting my head down and doing what I could without being noticed too much.

But then I stopped and really thought about the situation.

Here’s what I realized:

  1. GraphQL really was the best solution for what we were trying to do.
  2. I wasn’t some GraphQL prodigy. I just had the good fortune to have worked with it in the past and had found it interesting.
  3. My coworkers are really smart. Brilliant in fact. But we all have knowledge gaps. Instead of obstacles, those could be opportunities. I knew my teammates would love to study about a new technology.
  4. I liked my coworkers. I wanted them to succeed. And I wanted them to feel like they were equipped to make meaningful GraphQL contributions to the project.
  5. I liked the client. I wanted them to succeed, too. 
  6. If I did something to help out my teammates, I knew they would pay back the favor. And I was confident that in the future, I would need some guidance for things I didn’t know much about.
  7. I worked in an environment where embracing your pet projects was not only tolerated but encouraged.

GraphQL Academy is born

Taking all these factors into consideration, I knew I had to do something. So, I started developing an idea that became GraphQL Academy—a series of workshops that covered everything from the basics (e.g., schema design, type system, resolvers) to advanced topics (e.g., performance, security, caching). Because it was something I was already interested in, I’d actually been reading an awesome book about the subject, Production Ready GraphQL, and I used that as a foundation for the classes, basically converting each chapter into a session. Along with the book, I also incorporated content from articles I’d read through my own research, along with my own experiences. My goal was to synthesize as much material about GraphQL as possible into one place. I figured that would make learning it far easier for my teammates. With that, I worked on the lesson plan for my first class, created presentation slides, put together some speaker notes, sent out the invitation, and held my breath.

Laura presenting

To my (sort of) amazement, I started getting acceptances. I say “sort of” because I already knew my teammates were ready to support my initiative. They showed up, participated, learned, and even enjoyed themselves! It felt like a true success. From there, I created content for the next session, and then the next and the next. Soon, I had not only members from my project in the classes, but people from all over—other Amsterdam Reaktorians, as well as ones from New York City and HQ in Helsinki. There were of course some developers who were familiar with GraphQL and just wanted to sit in on a session or two to brush up on a specific topic or hear what was going on. But there were others that really had no background with this technology. Some were on teams that dabbled in GraphQL or were considering it for future use. Others had no immediate plans to implement their newfound knowledge but were happy to add to their storehouse. For instance, one Reaktorian was sitting on the bench waiting for his next project and came across the workshops on our events page. He used his downtime to immerse himself in professional development—with the added bonus of it coming from his company and coworkers, so the relevance was that much more pronounced.

What we learned

It’s been about eight months since the first GraphQL Academy class, and we just wrapped up our ninth and final session. Each lasted about 60 minutes and had a presentation, challenge and Q&A session. Topics included:

  • Fundamentals
  • Type system, schema design, resolvers
  • Expressive schemas, pagination, error handling
  • GraphQL servers – Code-first vs. schema-first, SDL artifacts, etc.
  • Security
  • Monitoring and security 
  • Tooling
  • Workflow

Here are a couple examples of what we discussed in our sessions. 

Schema Design
In order to start building a GraphQL API, we covered schema design in the first classes. Understanding schema design patterns enables us to use all of the power that GraphQL’s type system provides. But if not used correctly, it can lead to many issues like a considerable number of breaking changes, bad developer experience, unexpected behaviors, out of date documentation, etc. 

Client-Centric Design
There’s a practice called “client-centric design,” which is based on the importance of working with people who are familiar with the use cases exposed to the client. By collaborating closely with the domain experts, developers  address the real client needs instead of creating schemas that are too coupled with implementation details.

Now that the Academy is officially done, it can live on in archived form on Reaktor’s intranet for any employee who wants to take advantage of it in the future. Would you like to see for yourself what GraphQL Academy is like? Here’s a clip from our session on GraphQL feature flags.


The kind of openness the tech world needs right now

When I came to Amsterdam from Brazil with only three years of work experience, I knew I was joining a company that was literally as old as I was. I also knew they had hundreds of talented developers. I was sure I would have plenty to learn from them. What I didn’t realize was that I would have the opportunity to stand on the other side as well—that my teammates and even people from across the world who had never met me would look at me as their peer and be willing to accept me as their instructor. My age, my CV, and my gender were not obstacles for me to make a meaningful contribution to my team and my company. That’s the kind of openness the tech world needs right now. And people helping people is what the world in general needs. I’m thankful Reaktor has given me a platform to be able to contribute in some small way.    


Want to hear more about what’s made me who I am today? Read my Dear Future Colleague post here or listen to a podcast episode where I discuss learning by teaching. 

Sign up for our newsletter

Get the latest from us in tech, business, design – and why not life.