Ep. #24, Server-Side Rendering with Trey Huffine of Postmates

Brian Douglas: Welcome to another installment of JAMstack Radio. In the house, we've got Trey Huffine from Postmates. Trey, say hi.

Trey Huffine: Hi, everybody. I'm Trey Huffine, a software engineer at Postmates. Doing a lot of front end React kind of stuff but then also getting into some server-side things like Go and building out some exciting things there.

Brian: Cool, and you're flying solo. We wanted to have another team member here, but I'm going to ask you, "What is Postmates?" to see how good your marketing skills are.

Trey: Postmates is an on-demand delivery service. What we like to think of ourselves as,

the city is our warehouse. Anything you want to order, any time, you can Postmate it and it'll be delivered to you within 30 minutes.

Brian: Yeah, cool. My introduction to SF was also Postmates. I worked at a company that used, our office manager used, Postmates really heavily. Sorry, we're going to talk a little bit more about Postmates. Your logo is a bike messenger too. So the Postmates start is just bike deliveries?

Trey: Yeah, I think our founder started out delivering however you could. So bikes, walking, whatever, really bootstrapping the startup mentality. The idea is with the Postmate, you can Postmate anything. It's whatever you want, whenever you want to get it, it's there.

Brian: That's why our office manager... Because if anybody's familiar with SF, it's almost impossible to get across Market Street in a car. If you ever want to go anywhere, if I ever had to go, I actually just Lyfted. I was going to try to Lyft from here, because I'm actually at a conference at down near the mall area, Powell Street.

So much inside baseball right now about SF. If I wanted to cross, it's better for me just to walk and take the 20 minutes to walk anywhere in SF, as opposed to take a Lyft. I guess riding a bike is probably much better.

Trey: Biking's good, yeah. I just started doing a little biking as well. They have these new Ford GoBikes around, which are pretty sweet. I mean, taking those are way faster than Lyft or an Uber. It's pretty nice to be able to just get out and go, instead of sitting there staring at your phone.

Brian: Cool, awesome. Hopefully you guys will, if Postmates is in your area, check it out. I want to talk more about what you guys are doing at Postmates, technology-wise.

I first met you at a React meetup here in SF, at Postmates, and you had gave a spiel about how you guys started using Postmates. Not sure, exactly. I've seen a couple of your talks. I'm not sure which one of the talks was. But basically, you guys choosing to move forward with React and do certain things. It might have been a performance talk or something like that.

Trey: I can give you a history of our tech stack. Postmates used to be a Python monolith. We had Django templates, very structured and rigid and just not fun to work in as a front-end engineer.

Probably a year, year and a half ago, the front end was rewritten to a Node server, where we were doing server-side rendering. We were doing state management, using a model system kind of similar to Angular.

Brian: Were you around for that transition?

Trey: I wasn't. I joined about a year ago. So it was still not in production, but all the ideas had been formulated.

Brian: Yeah, that's interesting because I had Zack Argyle from Pinterest a while ago come in. And they were doing the same thing. They just had their own template thing called Denzel. And they switched to React.

Instead of getting rid of the Python, they ended up not going Node but going React on the front end, which is interesting. But you guys just went full hog, straight Node server?

Trey: Yeah, we're like, "Microservice." Cut it off completely and just moved entirely. That's been a ton of fun, learned a lot. But then also some great experiences to learn from mistakes we made as well.

Brian: Okay, so no Python code in the future?

Trey: Our API is still in Python, but if you're a front-end engineer, no need to touch Python.

Brian: Okay, very cool. Just take that JSON on, I assume.

Trey: Exactly, yeah. Make your API call, get your JSON and render out your views.

Brian: Cool, and I heard you guys are also doing a little bit of Go as well.

Trey: Right. We transitioned from a Node server into a Go server. We're rewriting our application right now.

Brian: You guys just don't want to stay put, huh?

Trey: Right, yeah, exactly. We call this our third iteration. But apparently there were a few more that came and went along the way, as well. We're pretty confident in this one. So far, everything looks great. Performant, visually it's fun. It's pretty great.

Brian: That's crazy because Netlify, the company I work for, we have a Rails server, which is like Mongo and a bit of Go as well. When I first came on, there was talks about maybe getting rid of the Rails side of it. But I think it does enough of what we need it to do. But I think everybody's really itching to try go out and rebuild the server. But I don't know anytime soon if that's going to happen. You guys are very bold and brave.

Trey: We definitely took it on and it's been a lot of fun to work with and just being able to separate your front end from your back end is pretty liberating to do. Because then you no longer have to worry about where the data is coming from, how it's doing. You just kind of get handed what you need, and you get to build it out. I think although it's painful at first, you kind of like rip off the band-aid, and then you're good to go.

Brian: Yeah, that's pretty crazy and it's funny you said you separate the front and the back end. You're literally doing the JAMstack, which is what this podcast is all about and why we're actually doing this and talking about it.

There's a lot of vulnerability in having everything all in one little server, one repo.

Having isomorphic JavaScript, whatever you want to call it, or a Python server, and rendering your templates and all that. Because then, when you want to do the transition, it makes it a little harder to if you want to change your server in the back end, you are really tied into whatever your solution is. Sounds like if you guys are separating stuff pretty well, then you can take these chances.

Trey: Yeah, exactly. Because now that it's separated, we're rewriting our front end entirely. But then we still have our Python, Django, API on the back end that's still doing the same thing. So we can iterate. We can move quickly. And we can kind of figure out what works best.

It also allows us, when we're deploying, we don't have to be in that main line. We get to do things separately and really move quickly and figure out what works best for us.

Brian: So having now a Go server but then also React on the front end. What I really want to talk about is the fact that you guys, when you did your talk about your performance on React, you mentioned that you guys are not doing server-side rendering. It was a question that came after your talk. I think actually in the middle of your talk.

I think it was almost like a collective silence in the room of, how could this guy be talking about performance on React and be a forward-facing company where you, I think SEO is probably a big deal for you guys.

Trey: Absolutely, yeah.

Brian: So talk about that. Like, why no server-side rendering? And how are you handling it today?

Trey: Our Node stack, when we first upgraded, it was being server-side rendered, and I guess the biggest issue is that it just involved a lot of complexity to maintain. You had to diligently check every package.

And then to render the code on the server and then match on the client became pretty tedious because there's a checksum in React that has to match. Well, up until React 16 at least, and if that checksum doesn't match, it wipes your entire DOM and rebuilds it.

A lot of extra things to worry about that we found were more of impediments than benefits for server-side rendering.

Brian: I did my intro to React with a server-side-rendered app for a previous company, and same problems. There was a lot of domain-specific knowledge. So if someone wanted to come and do a React code, that was easy to pick up. The Redux thing also took a little bit of time if you're using Redux.

But then when you get to the server-side stuff, actually getting the data back and rendering down the string, that was always the part where a lot of people were like, "I don't know. I'm not even sure if this is a good idea." And this was me, my intro was two and a half, three years ago.

So it was harder to sell people then, because you don't have all these blog posts and you're just finding on a regular basis that Trey is writing on Medium. Did you guys also have a problem onboarding new people on a project as well?

Trey: Yeah, I mean, that was definitely an issue trying to just understand what's going on. Like you said, with React, on the client side, it's easy. You load your JavaScript. You build out your UIs and it's a pretty small API to understand there and get things going.

But then, when you have the server-side rendering aspect, you have to worry about, do you have all your data? How are you going to get this data on the back end, parse it out into your UI then build it out? That's quite a bit of complexity but even simple things become difficult.

We have a React button that will let you do OAuth for Facebook, and in one commit, they introduced the window object to this package. It blew up our entire server-side rendering. It took us a day to figure out, what's going on? Why is this happening? So it's even small changes from the outside that seem innocent, can come in and just totally wreak havoc on your code.

Brian: Man, that is crazy. I ended up leaving the app that I worked on to come work for Netlify. So I kind of abandoned that to go work on the JAMstack. I haven't had any of those horror stories in my experience, but I know they're all out there.

I actually wrote a blog post recently on the Netlify blog about comparing the JAMstack to isomorphic rendering and the fact that... Server-side rendering, isomorphic server-side rendering--I use a really long word because I want to really paint it as an ugly way to approach it--but I compared it from apples to apples.

I took Addy Osmani's HNPWA, which is taking Hacker News and making Progressive Web Apps. I used some of his clones that he created and I also created, I took one of the Next.js clones to do Hacker News. I just benchmarked my version versus theirs.

When you look at the metrics and performance, mine was pretty much on par with everybody else. So the question that I had in my blog post was, is this even worth it? I think I wrote it around the time we first had met.

When I heard that and I heard the collective silence in the room where everybody's like, "No way. They can't be not doing server-side rendering." I was like, "Oh, I need to have Trey on the podcast to talk about this."

Let's talk about, I want to talk about performance, but I actually want to talk about SEO. Are you guys not caring about SEO at this point?

Trey: We actually have invested quite a bit into understanding it and learning it. We have a very experienced SEO person who's come in to manage that as well as David Byttow who wasn't able to make it today, former Googler who knows all about it.

The consensus was that it's not going to have any impact on the SEO. Google can run JavaScript. It's going to pull your pages and it's going to get all the content that it needs. In terms of SEO, we have an escape hatch where, if we need to add server-side rendering in, if we notice an impact, then we will. But as of now, we've noticed no real issues yet with loading the JavaScript, on the client side of building out the UI.

Brian: What's funny is that we continued to talk, as a JavaScript community, about server-side rendering and how important it is and we need to do this. But Google's announcement, it was 2014 when that came out. And they're like, "Hey, we can read JavaScript." I know this podcast could be listened to years from now, so the year today is 2017.

We're going three years since that original announcement of people continually doing server-side rendering and complaining that Google can't parse through this data, which is interesting.

The only gripe I've heard people say about this is that I think sometimes with the Google bots, they do fail every now and then. So if you have some weird JavaScript that's happening, and it takes too long to parse, then it will fail.

But I think, going back to the Progressive Web App Hacker News clones, as long as you're worried about time-defer spike, I think you're pretty much good. Make sure you optimize for performance. So then the question's now, are you guys concerned about performance now that you're separating? You're going to your JSON getting your data from HTTP. Is there a team that worries about that?

Trey: Definitely, performance is always an issue. You want to have the fastest, the snappiest app that you can. But as long as you're forward-thinking with it and make decisions with that in mind, you can really avoid a lot of those performance implications.

Code splitting is a help. Using tools that have been shown to really improve UI performance, Redux is great for us. That's one we've added to our stack. Using Reselect with that. There's a lot of things you can do to make sure your app stays performant and preventing renders on the React, preventing DOM updates that are unnecessary. If you have people who are forward-thinking and conscious about that, it's really no issue to make sure that doesn't happen.

Brian: I couldn't have said it any better. If you're just focusing on rendering an app as quickly as possible and not doing silly things like watching for select things and not worrying about teaching the next person server-side rendering and teaching how this works and why have two routers, and etc., etc. I think the pain collectively I'm seeing is that this is a solved problem.

One other thing I found out in my blog post is that the only clone that compared against mine, that was better, was because they were doing collective things from the cache when they're fetching from their JSON API. So it was server-side rendered but they actually were using a local cache. So with service workers and stuff like that.

Trey: Sounds like cheating to me.

Brian: Yeah, and I mentioned that in my blog post. It's not cheating. It's clever.

Trey: It is.

Brian: And if you're not server-side rendering, it still doesn't matter because you're using a local cache to do that on the browser instead. So it's really a great practice. I wouldn't have figured it out unless I looked into this little blog post and this retrospective in looking at, is this really worth it?

At the end of the day, server-side rendering is not really that worth it. I think some people, I know ZEIT has Next.js, so the problem's solved through and through. So if you need server-side rendering and you can't convince anybody to do it, then you're going to start a new project and reach for the next thing.

But then the other issue is, you're still tied into that framework. So then you have the same problem where you started, or where Postmates started, which it was Python monolith. Instead of Python now, it's JavaScript monolith.

T- Exactly, yeah.

Brian: So then we're just restarting the entire new cycle when we could just solve. We can do clever things with caching, like what I just talked about, instead of worrying about getting stuck.

Trey: Yeah, totally. I would definitely agree with that. I think caching is one of the big ones. If you have Redux or some standard React thing, it's just, throw something in local storage, and the middleware is very easy to populate and pull that out. I would definitely suggest that. With server-side rendering, I think it's one thing people have been convinced that it's something they have to do. And honestly, I was one of those people.

I was convinced for a long time until I had to do it and I found the troubles with it and then now that we've switched back to using just client-side rendering, we haven't really noticed any performance decreases. But the developer experience is much higher. It's much better.

I would definitely suggest only go to server-side rendering if you have a very valid reason to do it.

Because if you are doing isomorphic React, it's going to slow down your development speed. You have more to worry about. You're not really going to be able to move as quickly as you would if you just stay on the client with that.

Brian: Cool, and then, are you guys researching into anything like Progressive Web Apps, like making Postmates a Progressive Web App? I know we're days away from the end of the Chrome Summit and that's where they talk about Progressive Web Apps. Have you guys looked into that at all?

Trey: As we're rewriting this new one, it's not something that's going to be in our v1 release. We just want the product out there first. We're entirely rewriting the UI, entirely rewriting the front-end servers, so that the product at this point is our focus. Which is why we kind of got rid of things we didn't see necessary, like the server-side rendering.

But definitely, as we fill out this first version, get it released, then looking into things like Progressive Web Apps, making sure it loads very quickly regardless of your connection, things like that. There's always going to be something we keep in mind.

Brian: Very cool. Awesome. Just before we go to picks, I actually want to transition to a bit of what I've actually, I mentioned before, we actually started recording. I keep seeing your Medium post show up in my feed. Do you want to talk about, you mentioned a little bit, do you have React experience beforehand? And that's why you're just sharing knowledge to people?

Trey: Yeah, it's kind of two reasons. React is something I've been very excited about for a few years now. My company before Postmates, we actually weren't using React. So all of that was kind of on the side, still continuing to learn. And then when I transitioned to Postmates, I saw this opportunity to really take it to the next level and figure out, learn as much as I could.

The reason I'm writing articles is, one, to share the knowledge. But two, it helps me learn as well.

It's like, okay, if I'm going to put this out there publicly, then I better know what I'm talking about. So go through and learn as much as I can and then help other people learn the same things.

Brian: You've also done some local speaking, too, as well. You got any conferences you got booked in the future?

Trey: No conferences yet. That's the next step after a podcast.

Brian: For sure. Your brand is real strong.

Trey: Yeah. Definitely just trying to speak at some local meetups, get to know people. I say that's one thing that I'm pretty passionate about, in general. It's just trying to help build a community around software engineering and developers, because we have things like Hacker News, Reddit, a lot of ways to share knowledge but there's not as much individuality. We're lucky here in the Bay Area that we have meetups to go meet people but just

being able to find people to connect with and feel like you belong in this greater community, I think, is something that we should really strive for.

Brian: Yeah, very cool. Awesome. After you've gone through, you've been at Postmates for a while. You guys are now on the React train. Or they were on the React before you got there, but now they're really on the train. What's next? Do you guys think that you're pretty sold on React? Are you peeking at things like View or Preact?

Trey: I think we're pretty sold on React, especially with the license change. It's very nice to have that and not have that in the back of your mind. But yeah,

I think React solves all of our problems. Everyone enjoys working in it.

One thing I would like to do is get a little React native in our mobile apps. We'll see if I can convince them but not super confident yet.

Brian: Yeah, you should talk to some of these companies that are transitioning and doing these hybrid approaches. I know Netflix was doing it for a bit. And some other companies of the React meet at conferences. The way to drop it in piece-meal.

Trey: Definitely. I think AirBnB said at this point they have 90% of their app in it.

Brian: Oh, really?

Trey: Yeah. They've gone full on board. I know obviously Facebook is investing in it heavily. So yeah, I think it's something we could see shape the mobile application landscape, which is pretty exciting.

Brian: Awesome. I'm going to go ahead and transition us to picks. These are things that we're jamming on, things that keep it going throughout the day. This can be music, can be code-related. Mine tend to not be ever code related. But I do have one today. Did you have your picks all ready to go?

Trey: Yeah, sure. I'll go with two picks. Am I allowed to do two picks?

Brian: Yeah, you could do as many as you want.

Trey: I'll start with Ford GoBikes. Those things are pretty sweet. I haven't biked probably since I was 12. When I first moved to the Bay Area, I bought a bike, didn't know how to lock it properly and got it stolen within the first week. So these bikes have been awesome. I've been using it for two weeks now. Definitely jamming on some GoBikes.

The other one is kind of my passion project. It's something I've been getting into quite a bit lately. Gitconnected.com, G-I-T connected. It's just kind of like I was talking about, finding a way to build more community, meet other developers, meet people with common interests, share knowledge and just enjoy this world we live in.

Brian: Cool, how does Gitconnected work? You just login with GitHub and then you get to meet, connect git developers?

Trey: Right, yes. It's all done through GitHub. It can pull your projects, pull your data, and give a background of who you are pretty quickly. And then we have a posting feature, so you can post articles you found, start discussions on things you're interested about. Really, just give more individuality to yourself as a developer.

We also have a Slack channel to meet other people, have real-time conversation. So just a way to just connect and meet others who have the same interests as you.

Brian: Sounds like the LinkedIn for GitHub. GitHub, are you listening? Maybe they'll acquire this project. Are you using the GraphQL API at all?

Trey: Yeah, been using GitHub's GraphQL API. Actually, my first exposure to GraphQL in real project setting. It's been a ton of fun. It definitely changes the way you think about retrieving data from a server. So it's been pretty cool.

Brian: I'll just transition picks. I've mentioned this project before, but it's Open Sauced. And that was my introduction to GitHub's GraphQL API. So maybe there might be some collaborations, or connections I can maybe embed that into my project. But my project is actually an open-source project to manage open-source projects. And it's named Open Sauced.

I did a talk. Actually, I did a talk at GitHub Universe on this entire thing. It's a whole 30 minutes of nonstop humor, because it's all jokes. I guess I'm going to have to get into it. Basically, Gucci Mane, he made the joke about, he can't be lost in the sauce. Because of that, I made a project that was called Open Sauced, because you can't get lost in the sauce because you're not born with sauce. You've got to get the sauce.

Anyway, look up the Gucci Mane YouTube video where he explains the sauce. It's hilarious. That's, I guess, pick two. Look at that. I'm just rolling through these.

Another pick I have is Apollo Launchpad. I might have mentioned before, and I know we had the Apollo team here. But it's a great place. It's like the code pin for GraphQL. So you can actually test out building out GraphQL schemas without investing into the entire spec. So you don't need to touch the API.

He could actually just take a Rest endpoint and add it to there. Or you can just pass in just generic data right there within the variables there. So again, like code pin GraphQL. Pretty awesome.

My final pick is going to be, I watched the Walking Dead since day one. And I'm up to speed on the original proper Walking Dead show but I was never watching the sister show which is called Fear The Walking Dead. I just caught up to whatever the last episode that was just aired. I caught up within the last year, just piecemealing every now and then.

At first, I was not really into the show. That's why it took me so long to actually finish, what, two seasons now? I think it's three seasons. But it actually got a lot better. I think at this point, it might be better than the main show.

So if you want to skip ahead, just skip the first season. Maybe skip the first few episodes of the second season. And then it gets really good. So check it out if you're into the Walking Dead. If not, forget I even said that.

But Trey, thanks for coming into the studio and talking about Postmates and server-side rendering.

Trey: Yeah, huge thanks for having me. It was a ton of fun.

Brian: Awesome. And listeners, keep spreading the jam.