Talking About Your Own Work
Talking about your own work can be surprisingly difficult. Sometimes you don’t think to question why something is done a certain way until you have to explain it to someone else, at which point you realize you don’t fully understand what you were doing. Or, more commonly, you have an understanding of the nitty-gritty of a certain framework or library you were using but you aren’t practiced in giving a high-level overview of its purpose, pros and cons, and alternatives to someone who hasn’t worked with it extensively. This is why I love to teach -- and why I like to write blog posts ;) Both require you to put your thoughts into full sentences that give you a more complete and precise understanding of a topic you thought you already understood.
So, I’m going to write about about my previous work at Houzz to practice just that!
Houzz has two codebases: it was originally built in PHP and jQuery, but has been migrating to an in-house frontend framework that uses Node and React. This frontend framework still makes service calls to the PHP codebase to fetch data, but has its own logic for routing, middleware, etc. Service calls are made using ApacheThrift, which no matter HOW MANY TIMES I explain to someone, I cannot remember a good one-sentence summary of.
Ok, I looked it up for the 849th time, so here it is:
Apache Thrift is an interface definition language and binary communication protocol developed by Facebook for “scalable cross-language services development”. (Source)
In other words, Thrift allowed our JavaScript frontend talk to our PHP backend and do type checking on the data that was passed back and forth. It also has the advantage of allowing for binary serialization, in addition to traditional options like JSON and XML. Binary encoding is much faster, making it an ideal choice when transferring data over internal networks (as we are when we make a service call to the backend). Overall, Thrift was a good choice for us because we needed to interface between two codebases in different languages, and speed was a priority.
Thrift can also be described as an RPC (remote procedure call) framework, but there was hardly room in the definition for that so I am tacking it on now. What does that mean? RPC is a specification for how to interact a server, just like REST is. SOAP (Simple Object Access Protocol) is one implementation you may know that’s frequently juxtaposed with REST. RPC frameworks emphasize operations over resources. This table with some example RPC vs REST endpoints illustrates the point nicely (source):
Thrift is an RPC framework because you interact with the server via operations (e.g., getVisitorHomepagePhotos), as opposed to interacting via resources and HTTP verbs (e.g., GET /photos?type=visitorHomepage).
So there you have it! I spent a while in the previous posts talking about GraphQL in comparison to REST, but my own work was actually integrating it with an RPC framework.