JavaScript has spawned many different frameworks and libraries—each with some cutting-edge functionality, and each with its own set of challenges. In this environment, CTOs must balance allowing freedom to experiment with new tools while making sure the sprawl doesn’t become unmanageable.
Shawn Samuel, CTO of SaaS-based trading solutions provider LiquidityBook, says that to manage the sprawl of frameworks, componentization of products is necessary. Componentization allows the vendor to swap out products multiple times. For example, 12 years ago when the LiquidityBook launched, it went with a direct homegrown remote procedure call (RPC) mechanism for messaging. That was eventually swapped out for a hub-and-spoke ecosystem. Today, the company uses RabbitMQ messaging. “We were able to do that with almost no cost and extremely quickly because that piece was well componentized; we abstracted that away from the core system,” Samuel says.
Where it has run into trouble is that as a technology company it has to hire talented developers. As a result, it has had people come in and build decent working solutions but lacked cohesion. For example, one developer might build something using C++ and another used C# because that’s what the developer knew and could get it out fast. Inevitably, Samuel says, if you don’t pick your spots carefully you end up having to rebuild for things like database access, access to your configuration system and your Redis cache, and building a lot of core code. Then, as soon as you end up building the same concept in multiple places, you are unable to refactor—the process of changing a computer program’s internal structure without modifying its external functional behavior or existing functionality—and you’re unable to employ new technologies because you have to change three different things instead of one.
The LiquidityBook platform was built on a Java infrastructure, but the stack built on top of that uses jQuery and Knockout. “What we’ve learned is, decoupling in order to allow experimentation is a great concept, but it’s not as simple as that,” Samuel says. “You need to think about, am I really employing a new tool not just because it’s cool but in a place where I think I’m not going to pay a price for using it? Experimenting with new frameworks that sit on top of core-system components has worked very well for us.”
Samuel says this trend is a “pull-based, not push-based” evolution. As the consumer internet continues to offer new richness of experience, there is a different expectation level about user interfaces. Additionally, developers and—more importantly—institutions as a whole, are becoming more comfortable with open-source licensing.
“If I look at the investment required to deliver a new app with interesting new functionality, you’re now starting to see a difference of multiples in terms of the effort required, which drives people to start looking at these new technologies,” he says. “For me, everything else follows from that.”
Read the full article here.