Presentation: Enterprise Node.JS Apps in 2018

My job now is helping various teams make sure they're doing things the best way possible. If they're using React and Webpack or another set of tools, making sure that it's set up and configured well, making sure that they aren't making any common mistakes that we can help them avoid. Then, on the Node side, making sure people are using the latest technologies. I've been instrumental in helping our teams get upgraded to Node 6 and then 8, and keeping current with those technologies, staying aware of changes in the ecosystem, like Babel or TypeScript, GraphQL and other tools that have allowed us to do more interesting things and trying to keep ahead of the curb. Then working on turning the big ship that is PayPal engineering in a better and smarter direction.

What I want to show in this talk is how we’ve managed to deal with the challenges of maintaining large-scale node.js apps over time. When we build out these apps it’s difficult to predict how the technology and product might change. What kind of bugs and challenges are cropping up that we didn’t predict and how we’re solving them.  For example just as FlowType was coming out we were dealing with a lot of server crashes. It’s helped us a lot. I'll also talk a few times about how we tried to move forward too quickly, and we burned ourselves. It's okay to slow down sometimes and say, what we have right now is working fine. Maybe we don't need to jump on the latest trend every week. I've got to try Gulp and then I've got to try WebPack or Broccoli, and then I'm going to try this one or try that. Maybe it's OK to say, we're going to try this for a year until it stops working for us.

Anyone who's working on JavaScript heavily I think will benefit from this talk. All the technologies that I'm talking about apply on the server as well as the client side, so there will be benefits on both ends. But I really love to talk to the Node engineers out there, people that are working in JavaScript shops that want to figure out, I'm sick of having to upgrade my stuff every 4 months. How do I decide when to slow down and when to speed up, and I hope there are lessons from PayPal, good and bad, that shed some light on the process.

We're shrinking the Node part down. We've got GraphQL. We're doing more work there so the UI engineers can focus more on building in their environment and less than having to update our node servers. Right now, the full stack engineers say they want to build some new component for the user interface, so they build the UI part, and they also have to go on the server and update the REST APIs and do all this. We're filling it with GraphQL. We can really shrink our Node servers down to do a very minimal amount of work while the front end is able to do more and more. So, it empowers front and developers to continue to focus there without having to switch contexts into the server aspect. In some ways it is shrinking what Node has to do for us, but I think it will make us deliver better apps faster.