Ep. #28, Front-End Infrastructure at Coursera

Brian Douglas: Welcome to another installment of JAMstack Radio. In the house we've got Jon Wong.

Jon Wong: Hello.

Brian: Jon, who are you and what do you do?

Jon: I'm a Senior Software Engineer at Coursera. I work on the front-end infrastructure team. It's three of us, Lewis and Greg are on my team, and we work on the workflows, tools, processes that our front-end developers use at Coursera to build Coursera.

Brian: What is Coursera?

Jon: For those of you who haven't heard of Coursera, Coursera's an education platform. We partner with universities and industries all over the world. In fact, we have over 150 partners and they host courses on our platform.

We have 2,500 courses, from math, to history, to biology, to most recently, a Google IT cert. It's a platform for people to learn and to enrich their lives and transform their lives.

Brian: Coursera itself, you guys have partnerships through the colleges, but do you have to be enrolled in the colleges to start these courses? Who's paying money? Where's the money being thrown around?

Jon: We definitely partner with these universities. You don't have to be enrolled in those universities at all, and that's really great. Seventy percent of our learners are from not here in the United States, so that's really great.

That means that they can get that classwork from those schools, and then you can pay for it in a few different ways. Right now we have a subscription so you can pay a certain amount a month and you can have as much access to the different courses that you need. We try and group them to denote the sort of things that you're learning.

You could take one course, or you could take a group of courses, which is a specialization. And that sometimes comes with a project that you can apply your skills with. Even those specializations can add up, a group of specializations can add up to something like a degree.

You can get an undergrad degree in CS. You can get a masters in business administration, an MBA. You can get, as I mentioned before, a certification from Google to work in their IT department. All of that you can do without being enrolled with the university. The degree ones, it is a lot higher touch.

You do end up interfacing a lot with those universities, but for the most part you can do a lot of this from the comfort of your own home.

Brian: Interesting. As far as cost-wise, am I paying more or less than if I were to go to a university directly?

Jon: The things that you're paying for at a university are not just the education part. There's a lot of other things that are going on there. One, you can pay a lot less. It's a lot more flexible, of course. You can do it on your phone or on your computer. In comparison to other online degrees, a lot of cost is acquiring you, marketing to you.

Brian: Okay.

Jon: The thing is, you shouldn't have to pay to acquire yourself. Turns out that a lot of Coursera learners want to get those kinds of degrees and want to get those kinds of certificates.

We want to try and get folks to use Coursera for the little things and then show them that it can add up to the big things.

Brian: Awesome. I need to thumb through some of those courses to see if there's anything I can learn from it. Moving off of, we'll still talk about Coursera, but I want to talk about your role on front-end infrastructure. When I think infrastructure, I think Docker containers, and scripts to deploy my projects. What is front-end infrastructure at Coursera?

Jon: The way that I define front-end infrastructure is again, the workflows, tools and processes that help front-end developers do their jobs. That can start with things like scripts that you run on your computer. It could be your Babel setup, it could be your Webpack setup, it could be how your editor works.

It goes even as far as how we bundle your application, how we deploy your application, and even high-level things like what technologies do we use? Do we use React? Do we use this version, that version? Are we using things like GraphQL?

That's spawned off of the realization, as we're building these really big single-page applications, that it wasn't scalable to have product teams solve all their problems. We needed a few folks to really spend their full-time job making sure that we were making the right decisions there.

Brian: Yeah, that's a big point that you make at the end of that. The product teams are very... I came from product. I actually worked on the Netlify app for a while, and I was very knee-deep in shipping features and making sure the app worked all the time.

I wasn't really considering whether I needed to update my React to 16, or I need to re-update all these other dependencies. Do you guys handle the dependency management as well as part of the infrastructure play?

Jon: In the past, the biggest dependency management choices we made were to even get to a point where we could make dependency management choices.

Brian: Okay.

Jon: In the past, we used Backbone. We used those sort of things. The ecosystem didn't really evolve that much. Once we made choices like moving to React and moving to Webpack, then we got the ability to use those third-party dependencies.

Nowadays, we do make a lot of decisions as to, are we using React 16? How are we dealing with deprecation areas? Are we using this other third-party library? Is it compatible? We make a lot of those choices and make sure that we have the right amount of libraries and modules for our developers.

Brian: Cool, so it's almost like you're, are you not attached to certain projects within Coursera? You're kind of attached to the front-end ecosystems. Are you coming into a team who maybe is going to take a new project on, or a new system? Are you guys going to start playing around with View?

Are you guys the one that basically, you're taking the time to see if this is going to work? It's almost like, I guess what I'm getting at, it's almost like you're internal contractors where you're not attached to a project but you come in to provide feedback and support. Is that how it kind of set up?

Jon: Yeah, that's a pretty good way of talking about it. In the past what we've done is that we'd find, again, we serve our product developers. So we want to make sure that whatever we're working on feeds the product being made. And so they'll come with some requirements.

In the past, our switch to React was necessitated because we had a really interactive application. In this case, was creating courses on Coursera, that needed something that could do the data mining and all that sort of stuff. The team didn't exist at that time, but there was a few folks that knew a lot about this and really liked this kind of work.

That was maybe the first time that we started seeing that we needed people to jump in and be the special ops team and really get in there. And then today, it's the same thing for things like GraphQL where we have problems that the product developers are raising to us.

We sit with them, we work with them, we integrate with their team. We get a solution working, make sure that they understand it and then we figure out, we handle the in front, handling keeping it up and running, keeping up the maintenance and that sort of stuff, and then continuing to make sure that it's useful for product developers.

Brian: Cool, yeah. You mentioned GraphQL a couple times too, as well. The listeners know after listening to so many episodes I'm a big fan of GraphQL. Are you guys using GraphQL in production at the moment?

Jon: Yeah, we use GraphQL almost on every page. Maybe smaller pieces. We do a piecemeal approach to it. We used a sort of homegrown version of a very similar thing where we could do field selection, and that sort of stuff, but it wasn't nearly as advanced as GraphQL. Then we experimented with a couple of applications as a whole, switching over to GraphQL, and now we have the ability to just drop it in anywhere on a page.

Brian: Cool.

Jon: We're still working out the kinks, but it's certainly a big piece of our infrastructure.

Brian: Taking on something like GraphQL, who handles the education of these sorts of switches and decisions that are made? If you ever use GraphQL on a different page, are you guys also in charge of educating the rest of the front-end team to get them up to speed on whatever the newest and greatest thing is?

Jon: Because we have a little more time and because we're separate from the product teams, like you mentioned, we do have a lot of time to explore and figure out all the bumps along the road before we get to the point where we say, okay, this is shippable, or this is something that you can use.

We generate then a document that tries to highlight what is specific about GraphQL that's maybe difficult to use at a place like Coursera, but not the technology itself. We try and outsource all of that to the ecosystem. We have what I like to call...

We want to make sure that we have Googleability. We want to make sure that developers can solve their own problems as much as possible.

We try and make sure that if there's a solution out there, that we're not trying to hack it and make it our own all the time. Sometimes you need to, but ultimately, we want to make it something that's available outside. We'll follow that up with in-person workshops where we'll go through and do some introductory projects.

We'll make sure we'll have things like working groups where we introduce, at a high level, certain constructs and things coming down the line for GraphQL development. We use code review as a really great way of disseminating a lot of that information. In the future, I think we're going to steal some ideas from you and actually have people write some GraphQL from scratch.

Brian: Okay.

Jon: Do the whole integration and do the whole process that we did to learn how to use GraphQL.

Brian: Awesome. The Googleability, that term, being able to have the developers solve their own problems. Was that part of the reason why you guys switched over to GraphQL, as opposed to doing your own homegrown thing?

Jon: Yeah, absolutely. I think what we found with our caching client at the time, and the caching client, it's called Naptime JS, which is just an interface to a lightweight REST framework...

Brian: Oh yeah, the listeners are going to miss the joke, but yeah, that's actually a clever name.

Jon: Yes. A big thing was, maintaining our own caching client, we realized was not one of the things that we really, really, really cared about. The technology around the API was really important, but having to maintain a JavaScript client for that, for just ourselves, didn't make a ton of sense.

So when we saw something like GraphQL, the big tool that blew my mind was GraphiQL, which was the graphical interface for GraphQL. A big piece of that was being able to explore our entire API ecosystem.

We have something like 700 different API endpoints that are in REST, and now they're all available in one place via GraphiQL. That was just mind-blowing to me, and something that we weren't able to do before.

Brian: How big is Coursera, as far as people-wise?

Jon: We're about, I think, 275 full-time. Our engineering team's probably around 80 people, and our front-end team is probably around 30. We also support some of the mobile teams that are using React Native.

I would say we probably support around 30 people on the front-end side. Of course, the back-end developers are also using and utilizing those APIs, and of course, they are helping provide the data for the GraphQL parts, too.

Brian: Yeah, you guys must be a pretty popular team in hack-day projects. When you guys have hack days, a lot of people trying to get the infrastructure team to take a look at their code?

Jon: Yeah, I think a lot of it is the deep understanding of things like Webpack and that whole technology stack. There's so many advanced configurations and things that you can do with it that we don't do on a normal day-to-day basis.

During a hack day you're like, I want to make this thing 20 times faster. It's like, yeah, I have a solution for you, but it's going to take some work.

Brian: I'm actually working on a blog post right now that's not going to be, it'll probably be out way before this podcast because I basically have it written. I'm just getting other people to read it.

It's basically comparing all the build tools together. Browserify, and it went back to that, Gulp, Webpack. I also used Rollup for the first time to test it out, and basically because, I forget the Preact creator...

Jon: Jason Miller?

Brian: Yeah, he came out with Microbundle, which is built on Rollup. I'm like, I basically rebuilt the same app on using all of these different tools. I was like, oh wow, I could see where the ecosystem... Because like I didn't really get in the front-end development until Webpack was just coming out, before even 1.0, and then basically React is what got me to use it more.

I didn't really have the experience of all these other tools outside of Webpack, so I didn't have all the wait and problems that came up to it. I definitely appreciate communities, and like what you were talking about, picking tools that are Googleable. So that way people can solve their own problems.

Webpack literally pushed off their 2.0 release a couple years ago because the documentation wasn't ready. I think that was a really good move because once the documentation was there and they shipped it, it was much easier to tell the rest of the team to say, "Webpack is the way to go here in the documentation. Check this out. Code splitting, it hurts to do but eventually it'll get better."

It's gotten better, and I think it's pushing along some of the things you've been echoing, and I'm just trying to echo those things as well.

Jon: I think the Webpack community, especially Sean Larkin and then Tobias Koppers, they've done an incredible job over the last couple of years. Because I do remember right when Webpack came out for the first time, we evaluated and we said it's too complex. We can't do this without documentation, we can't do this without support.

In fact, four years ago when we were doing this evaluation we made the decision for me to write our own version of it at Coursera. Right now I'm dealing with getting off of that legacy piece of technology. To your point about the ecosystem, it's evolved so much in the last two years that it can also get a little overwhelming.

That's where the front-end infrastructure team is hopefully intended to shape how we interact with the ecosystem, and how we take things on, and not take things on.

Brian: Yeah, and I think evolve's an interesting word. I also think it's matured as well. Even a couple years ago, and I think I would've loved to have someone like you on my team a couple years ago during the whole JavaScript fatigue that was going around all that time. Because it seemed like every couple months something new was coming out.

Whether or not they were valid, or whether or not we still even look at them nowadays, you didn't know what was going to be legit. So you had to try everything, or you had to just give up and not do anything. But I feel like now with some of these other tools like View and React, and even Angular is still around with its multi-levels and versions.

I think we've learned from that phase, so now we have more maturity when it comes to choosing and building our frameworks, and also building them to last.

I don't think React would've been just as big if we didn't have not just Facebook, but also other large companies backing it.

I don't think Webpack would've been just as big, or would've lasted as long, even though other things were coming up during that time, if other people did not throw their money in front of it and say this is what we're going to use for a while.

I think that's helping, and I think it's making it easier, and I think it's making it easier for individuals like yourself to actually be that infrastructure maintainer of the front-end. Because it's been like that for years.

We have infrastructural leads at Netlify as well that handle mainly our back-end. Front end's basically all managed by the front-end. We're much smaller, so obviously we're not going to hire one person to do all our Webpack builds. But someday I think we would probably mirror the same sort of hiring architecture inside of companies. I think a lot of companies would probably interested to know this too.

Jon: Yeah, you'd be surprised. A lot of companies already have this role. Pinterest, Facebook. They have different names: web infrastructure, presentation infrastructure, platform UI, platform infrastructure. But some of these big companies do literally have one person whose job is to manage their Webpack builds.

Which might be a little much. I think it speaks to where we could have some development in that particular part of the area. When you make these big applications, it does take a little bit of work to manage it all.

Brian: Yeah, and I think it's just again, this is a front-end infrastructure, this maturing to the fact that we are now realizing we need to actually pay attention to what we're throwing on the front-end code.

Now I'm really glad that testing is more in vogue in the JavaScript realm because a couple years ago you just wrote JavaScript into this work, and it didn't matter if you had weird Jade templates, or if you did CoffeeScript, or if you did regular JavaScript. It'll just work forever. Eventually we found that that wasn't the case.

I guess the negligence of the way we wrote front-end code, I'm appreciative that we have some structures and infrastructure basically in the way we do code.

Jon: I think that makes a ton of sense. We never really needed complex applications in JavaScript, so we never really needed the tooling around it. Now that we do, what's interesting is that, as you mentioned before with back-end infrastructure, it's the same ideas, right?

I'm finding as I'm working, if the front-end infrastructure team is alongside the back-end infrastructure team at Coursera, and we share a lot of ideas and we'll say something like, "Here's some problem." I don't have something off the top of my head, but back-end is like, "Oh yeah, we solved that two years ago." And so it's like, these are not new ideas. They're just applying old ideas in a new place.

Brian: The reason why we do this Podcast, too, the whole JAMstack, it is another term for front-end. But it's like another term of more mature front-end where a lot of the processing power and the things that you were doing infrastructure-wise in the back-end is now being shifted to the front-end.

I just spent a couple, I guess a whole week, on building a release generator, where I'd built a serverless webhook to basically watch my GitHub repo. And then whenever a release is cut, it sends a tweet. Then it also sends a blog post based on the same release.

Whether or not you're following the repo, or you just follow the blog based on whatever's been shipped. This is just a drop-in replacement for some automation that I would normally have to send to my APIs I can now just have live as part of my front-end code. The code itself lives on the blog itself, the actual marketing blog site for the documentation.

It's kind of amazing, all the work that I've done that I don't need to attach this to the actual project itself. I think more and more we're finding, as we have things like Redux was kind of like... Redux, I actually did Ember Data before that, but it's having the idea of having data on your front-end, and having that data layer for your front-end has also been a bit of a shift.

I know it was a couple years ago that we had this happen, but it was interesting to watch that transition happen. When now, we no longer have the same problems that we had about, "What data are we getting from the API?" I don't need to go back to my back-end developers and say, "Can you re-serialize this data so it comes out this way?"

I can just get all the data, add some Redux actions, and then I can present the data in the way I want it. On top of that, GraphQL's an even better example of that, is that now I just get all the data and I can do all the querying based on what I need. It's been an interesting transition to watch.

Jon: Absolutely. I think GraphQL is one of the most interesting developments in recent years around that, to actually solve the problems that product developers have. I even know that, for some companies, their workflow consists of the product developer writing the actual query, and even if it doesn't exist yet, and propping it up on the server, and sending some mock data.

Suddenly you have a well-typed contract for what you're going to do between the front-end and the back-end, and I think that's just the Holy Grail of being able to design and build products easily.

Brian: I can't remember if I saw a talk on that, about two-step development in GraphQL. It was either someone told me about it and they were submitting it, or I actually did see a talk about it. I can't remember what it is, but the idea of literally having the front-end no longer being blocked by the back-end, and this proceed as normal.

When you have kickoff meetings, and we've been doing this as well at Netlify, you have kickoff meetings with design mocks, and no one is blocked waiting for APIs to be generated or front-end to be generated to see how it works.

Everybody's working at the same speed, or faster or slower, it doesn't really matter. But no one's blocking each other. So then if the front-end has their mocks up and it works based on the design templates, that's good. If the API is already done, the API is done, and no one's sitting around waiting for the next thing to do.

Personally, as a developer, I've spent some time where I've spent at least three or four days waiting for infrastructure or back-end to finish what they needed to do, or stop putting out fires over here and there, to then ship me some code. Nowadays I can just ship code and then move onto my next thing, and they can ship code and move onto the next thing.

As far as GraphQL, internally how are you guys seeing GraphQL performance-wise, integration-wise? Are you guys happy you made the move?

Jon: Yeah, I think it solves a lot of things that we had problems with. One was that it was really unclear what APIs could provide. Even though we have a schema language for our APIs, it wasn't exposed in a way that you could say, "Okay, what are all the possible things that could happen here?"

Beyond that, because we have so many types, we knew that you could theoretically traverse between the different types. But in REST that's not super straightforward. We have the concept of traversing one level deep, but with GraphQL you can nest infinitely and it's a lot more expressive in terms of how the relationships are like.

For example, going from a course, to an instructor, to the instructor's profile, to the profile link, that's a very easy construct to make. But in REST, that might be three or four different calls. But for a product note, it's just a very simple, one query that you make. I

n terms of integration, we took a pretty novel approach to this, which was we had all of these REST APIs that aren't necessarily, air quote, "GraphQL conventions," in terms of writing queries that make sense for your product, but they serve the purpose of exposing data.

So what we did is that we actually use that schema, the schema that we were already using for our back-ends, and auto-generated GraphQL schemas from that. And so once we figured that out, we basically were able to bolt on GraphQL support for all of our APIs at Coursera, rather than having to do that one piecemeal and having to hand write a lot of resolvers. It just does it automatically.

Brian: Yeah.

Jon: That made the adoption of GraphQL a lot faster and a lot easier to figure out. I think the one thing that back-end developers who still don't have to make anything specific, they just write the same kind of REST APIs that they were doing before, they just have to figure out how to link between things, how to traverse between different resources.

That's all been really great just because we have to support our REST endpoints for our old applications, for our mobile applications. We don't intend to deprecate the REST API just yet.

Brian: I think that's smart too, because I think everybody's really bullish on GraphQL, but I think there's a lot of things that haven't been solved yet. There's a lot of ideas that are out there that are just in spec review. Some haven't been released, like live queries, and stuff like that. But it's interesting to see the GraphQL community being very reserved in their approach.

I'm still waiting for some of these larger companies like Coursera and Pinterest and Airbnb to start talking about performance and how they solved this and this. Because I would love to solve those, but sometimes I have to just ship code. I would love to see what happens by the next GraphQL summit next year, to then start picking apart some of these blog posts.

I forget his last name, he was just on the GraphQL Radio, but Jason Lengstorf? I'm going to just butcher his last name, but I literally had dinner with him during GraphQL summit, and his approach with the GrAMPS framework and how to integrate things was really eye-opening.

It was probably the most detailed explanation of GraphQL in a company, and I really, really appreciate that. I'm looking forward to more examples and stuff like that, so I can start solving problems, but also don't have to, I can source to community just as you were saying what you guys are doing internally at Coursera. Netlify, we're just shy of 30 people.

We don't have tons of bandwidth to go off on little tangents. I tend to go on tangents, so I did do a lot of GraphQL. Yeah, it's a lot of fun.

Jon: I think the community and the ecosystem has done a really great job of providing the tools and things. GraphQL itself, by the nature of having a spec, and having a schema allows for a lot of, there's constraints. But it means that you can be real, you can kind of go wild within those constraints, which is really nice.

We've seen a lot of development in both the developer tooling ecosystem, as well as the runtime analysis, Apollo just released there. Apollo Engine, that's really interesting. There's a lot of hosted solutions out there. Graphcool, AWS, AppSync.

Brian: Have you tried AppSync yet?

Jon: We poked at it at Coursera. We're kind of locked into the AWS Cloud thing. That seemed like a pretty good solution for us. We poked at that. For some context, we have our own homegrown, basically wrapper around Sangria, a Scala service that deals with our GraphQL and stitching our schemas together. We wanted to find something that maybe is a little less, something that we don't have to worry about as much.

AppSync, it looked like it was really, really simple. We basically can click and modify some configuration and allow, one, you upload your schema that you create in the schema definition language, and then you define resolvers, that might be AWS Lambda functions.

Then they have a particular programming language called, VTL or something, so you can do some basic manipulation of stuff in their resolvers. And then you can have those resolvers hit DynamoDB.

To your point about having the ability to do a lot of work without having to wait for back-end and waiting for infra, you can just send everything to basically AWS Cloud. Of course you have to pay for it, but you can have that entire GraphQL to storage and back again, all in AWS.

Brian: Cool. I have a long list of things I need to try out. I'll just add it right on the bottom. Line number 35. One day I'll get through that whole list. Jon, I really appreciate you coming in and talking about Coursera, and what you guys do as far as infrastructure goes for front-end. But I'm going to transition us to picks.

These are picks that are things that get you going, things that you're jamming on. They can be program-related, they can be food-related, they could be not related, which sometimes I do have some unrelated picks. If you don't mind, I'll go first, and I'll let you go last as our guest.

Jon: That's cool.

Brian: My first pick is going to be The North Pole show. I actually backed a kickstarter last summer, it was a kickstarter for a YouTube web series. Actually, it was six episodes. They basically talked about North Oakland, and how gentrification is happening. It's actually, it's really, really funny.

I think the first episode's a little slow. I think that was their pilot that they had to put up on Kickstarter. The rest of them are actually really funny and good. I mention it as well because they film right in my neighborhood. Most of the shots are right outside my house. I won't tell you where I live, but it's pretty close to where those shots are, and in the house they hang out in is also right down the street from me.

I'm not sure who lives in the neighborhood, or how they got all those spots and stuff like that, but I actually saw them filming whilst it was happening, and I heard about the kickstarter, so I backed it. I was like, oh cool, I'll back this thing since they're ruining my neighborhood.

Just kidding, they're not ruining the neighborhood. It's a good web series. It talks about a very sensitive subject for at least Oaklandites. So I definitely recommend checking out The North Pole show.

Another more technology-based pick, it's going to be Netlify functions. It's a new feature that we actually just put out in alpha. By the time the podcast comes out, we'll probably put it as a beta, and we'll open it up for everybody to use.

It's a way to do serverless based functions within the context of Netlify app. You can deploy a static site, or a JAMstack site, rather, and also have functions run. You can do a lot of really creative things that hopefully by then, by the time Podcast comes out, I'll have some blog posts and examples to share.

But that example about the release note generator is a Netlify function that watches GitHub repos, and then ships blog posts onto your site. Jon, do you have any picks?

Jon: First of all, those picks sound really great. I really want that release generator. I've been working on some open source stuff, and I really need that automatic tweet release thing. I'll keep my eyes out for the Netlify function.

Brian: Cool.

Jon: I have a couple picks. One is from a technology standpoint, which is really interesting, it's the Apollo Link state library that Peggy Rayzis has been pushing and working on. I've talked with them about this a lot, but I really like the idea of being able to resolve client-side data using GraphQL.

What that does is, that you might not need Redux anymore, which is great. At the very least, you may not need to interface with it the same way. You can use GraphQL as your API for literally everything you need. Everything's well typed, it's all available the same way, no matter whether it's on a server or a local piece of data. That's really awesome.

The second thing is at Coursera we just released, I think two weeks ago was the Google IT cert. It's a certificate program that again, is hosted by Google. They made all the content. They intend to hire folks out of this.

This is the actual coursework that they use to train their employees, so it means that you don't need a degree to work, certainly on their IT team. We have a bunch of other hiring companies that are going through that process as well.

I don't know, for me, it was I've worked at Coursera for four years now, and I think that this is one of those moments where I'm just like, this is really cool. I'm really proud to see people taking that coursework and getting these high-paying jobs, I would imagine. Especially at a place like Google.

Brian: Yeah, that's exciting. I definitely have some people who are currently thinking about college, or going back to school. I might even point them towards that Coursera course to see if that works out for them, before paying for a full college tuition.

Awesome, I'm actually really happy you mentioned that. I'm also really glad, again, that you came in talking about the jam and what you guys are doing on the front-end infrastructure. Jon, hopefully you have a good ride home. Stay safe. And listeners, keep spreading the JAM.