July 26, 2018
Inside the LinkedIn office at the Empire State Building in New York City, we routinely hold a series of meetups covering topics that range from web and mobile to distributed systems and video technologies. The LinkedIn NYC Tech Talk series serve as a place for the New York tech community to engage with experts in the field, learn from each other, and share their best practices.
We would like to thank everyone who attended the event for a great night of discussion and for developing new ties within the community. For updates on upcoming events in the series, please follow the #LinkedInNYC hashtag, subscribe to the @LinkedInEng Twitter account, and join the LinkedIn NYC Tech Talks Meetup group. For those who weren't able to attend, below is a recap of the talks as well as a video recording of the speakers.
Compilers: The Next Frontier in Web Performance
The Joy of TypeScript
“I have a very severe open source addiction,” Robert Jackson announced in his introduction. However, Robert admitted to not knowing much about TypeScript initially, when he argued against it with Tom over his blog post, “What’s the Deal with TypeScript?” back in April 2017.
Since then, Rob became a TypeScript convert. In his talk, Rob took us through the joys of TypeScript and where we might want to hold off on it.
“How is this different from CoffeeScript?” Robert rhetorically asked the Tech Talk audience.
Robert posits that four key TypeScript Design Goals explain the safeguards it provides when we use it. TypeScript must:
- Impose no runtime overhead on emitted programs.
- Align with current and future ECMAScript proposals.
- Use a consistent, fully erasable, structural type system.
TypeScript can be leveraged for minimal cost because it produces no overhead while still allowing the code to be readable for debugging purposes and future-proofing the language. There are, however, some caveats to it.
“We're not going to take a major version bump because there was a bug in the compiler where it failed to identify early errors, even though that's technically a breaking change,” wrote Ryan Cavanaugh in a GitHub issue about TypeScript.
The reason for this is that “any compiler change could result in a breaking change,” said Rob. This is similar to fixing a bug in an ESLint plugin, where the linting bug might be fixed, but then you end up breaking someone else’s real-life work because of it. He believes this is a messaging issue that needs to be resolved, but not a deal breaker.
The upkeep costs, however, are a fair price to pay for the benefits, from syntax discoverability, which allows us to catch errors before execution, to editor type integrations, which provide features such as autocompletion, to finding file definitions and the actual file itself.
What is LinkedIn scale? Tom Dale discussed in his talk that LinkedIn supports over 560 million members in 24 different languages across more than 200 countries. This is achieved through the hard work of hundreds of UI engineers in offices in over 30 different cities in vastly different time zones. While most members might be familiar with the LinkedIn flagship application, we also support a multitude of other products such as Sales Navigator and Campaign Manager.
To coordinate across the different product teams, the Presentation Infrastructure (PI) team provides a platform for developers to create sites that are fast, maintainable, and secure. LinkedIn has heavily invested in next-generation web application architectures and technology. In this talk, Tom also covered how hundreds of engineers spread across different offices and time zones build modern web applications.
The workflow engineers have to go through to build LinkedIn’s web applications directly affects how the engineers build it. For example, the 3x3 strategy of releasing the application three times per day with no more than three hours in between code commit to it running in production ensures that the feedback loop is always present. LinkedIn’s code review guidelines even require that all code pass a code review by a product owner and a platform owner and be subject to static analysis and automated tests.
The Presentation Infrastructure team also learned that doing web development sustainably and at scale means that LinkedIn needed to standardize, optimize for change, and empower product teams. Tom mentioned how standardization helps reduce the number of decisions a team has to make, since “those are decisions, but they are not important ones for the team.” There are also fringe benefits for standardizing your stack, such as increased leverage of tools and products you build and the ability to respond.
Another lesson is to optimize for change, even at the infrastructure level. We should “prefer declarative systems, [which] gives you as the infrastructure builder a lot more room to change,” said Tom, as it provides us with the freedom to try new approaches without rewriting apps. Luckily, when everyone in the company is on one stack, it makes it very easy to automatically migrate, with some investment in automated tools that produce a huge impact.
Finally, we need to empower product teams, as they will act as your strongest allies for using the platforms we build. It is good to get feedback early before committing to a direction and use RFCs to give other teams ownership over the infrastructure they will use every day. Make sure that there is an escape hatch for the rare edge cases where engineers need a supported way to break out of the opinionated system to do what they need to do.
Thanks to Chad Hietala, Robert Jackson, and Tom Dale for presenting their talks and to Siva Visakan Sooriyan, Alex Easton, Anne Trapasso, and Anita Desai for organizing the meetup. This would not have been possible without the many volunteers from LinkedIn as well as all the attendees for making the meetup a success!