Shadaj joined us for a second internship this year from Cupertino, where he took the train every morning to work with us. He's been coding since the age of 6, loves Scala, robotics, and open source, and will be starting university at Berkely in the fall.
Shadaj joined the open source team and spent his summer building the Apollo CLI and a VS Code extension for Apollo and GraphQL. Building off his work on apollo-codegen last summer, he combined the apollo-codegen and apollo-cli projects into one, and built the beginnings of our VS Code extensions while leveraging those repositories and the Apollo language server. He worked closely with our open source team and community members to get the momentum on these two projects started, and they'll be released in full at GraphQL Summit in November 2018.
Interview
What made you come back for a second internship?
What's really interesting about Apollo is the mix between open source and commercial, and that's not really something you get anywhere else. It's an interesting experience because it lets you both work on product and communicate with community members because you have to know where to take your project and make sure it's explained well to the public. That's something that's very unique to Apollo. There are so many interesting projects at Apollo because we're working on very cutting edge technology. The types of project and the type of work you get to do with GraphQL are a lot more interesting and extensible than with REST, for example.
I got started last summer with apollo-codegen because I was really into Scala. Codegen is designed to make GraphQL more useful as a statically typed language, and it started out with GraphQL support in TypeScript and Swift as our intended targets. With TypeScript you want to handle the data you're receiving in a type-safe manner. Because GraphQL is statically typed, we know what the data should be and what the shape should be. We know what could be nullable and we can make sure you're not going to render or call functions on something that doesn't exist. You can understand the shape of your data enough that you can predict the shape of your component.
How would you characterize this summer for you as different from last summer?
This summer I already had a lot of context coming in, and I was able to have more control and lead the direction of the projects I was working on. Mostly this summer I was the primary developer on the Apollo CLI and a VS Code extension we're building. Unlike last year where I was more of a team member of a larger project, which was Apollo Client, I was leading the CLI this year. It was a very different experience because I had to make decisions about which directions we should go in. It was up to me to balance the desires of different users and to figure that out.
How did you go about making decisions?
Once I got into work on the VS Code extension, the first goal was just building really good code completion. There were a lot of gotchas with the original projects where there were some hidden bugs, so the first phase was addressing these and focusing on the experience of making writing queries as fast as possible for client developers. The work there was very obvious and defined.
Moving beyond that though, we had to think about how to make the actual GraphQL development experience more efficient. There were two primary ways that I thought we could improve. The first was context switches, which is where we came up with the idea of running your queries directly in your editor and built a query execution feature. With it, you really don't need GraphiQL or GraphQL Playground anymore, everything is right there in your IDE. The second part was making the decision process when you're writing queries more efficient. When you're writing up queries, you need to figure out what data you need and that's relatively straight forward. With features like @defer though, you now need to think about how that data is loaded. There the decision making becomes a lot more nuanced because you have to think about how long it takes your data to load and figure out how to partially load your components.
What's been the same this year from last year?
The Apollo team has been growing recently but everyone's values and vision is still the same. That was one of there really nice things, and I think Apollo as a company has a fantastic culture and strong communication between teams. Even talking to the founders over lunch and getting to ask them questions about where they see the company going is something I really enjoyed.
What do you think the future of GraphQL is?
I think what GraphQL has really shown is that it's possible to develop general specifications that still have lots of developer tooling around them. GraphQL has shown that you can have the advantages of having a more general protocol that can be implemented in a variety of different servers in the backend and have a lot of different client options on the frontend, but as long as you're using GraphQL, you'll have access to a wide variety of tools.
What makes Apollo stand out?
The really stand-out thing of Apollo is the independence that the team gives you. If you make a decision and explain the reasoning behind your decision, you’ll have the team’s support and everyone will back you. You're free to suggest the direction things should go in. As long as you have a solid discussion and explain the reasoning behind your thinking, everyone will be supportive of you in those decisions. Even as a first-year intern at Apollo, you have the opportunity to feel like a leader of the project you’re working on. The definitions are given as intended end goals rather than specifications for how the end goal can be reached.
Any new passions or hobbies this summer?
Getting ready for college has been different. Last summer I was working on my college apps on the train to and from work. It's nice to not work on essays on the train. I'll be going to school close by (Berkeley), so it's not a huge shift for me. I picked up speed running as a new interest this summer :) They come up with a lot of interesting exploits, like overflows in buffers that track the characters speed. There are a ton of ties to software development within that community. I work on a bunch of side projects during my summers, mostly open source stuff.
What advice would you give to next year's interns?
Write things down. Towards the beginning of my internship I was doing a lot of things in my head. If you write it down you become a lot more efficient, humans are meant to handle one process at a time. We use Quip at Apollo and I made myself a board with a big list of things I wanted to work on all the time, so I put all my ideas there and could jump to work on those things whenever I had spare time. Keeping a backlog and a todo list.
On the collaboration side, having frequent syncs helps a lot. I had a bunch of 15 and 20 minute meetings with my team members to talk about where I was at any given point, and it helps keep everyone on the same page and discuss ideas.
Any closing thoughts?
Even if you're working on the commercial side of things, definitely try and get involved in the open source side of things. Getting to work on open source, even if you're not working on it 100%, is really eye opening. There's a world of collaborators and maintainers, and last summer was my first real experience working with a lot of people in those communities. It wasn't something I'd really considered before. Apollo has really great open source mentors who can guide you, and working on open source is a really fun way to code and something everyone should try out.