Data Wants Freedom (alt. Thrift Sucks)
As a continuation of my previous post, let me mention what happened with the Thrift experiment I blogged about some time back.
Thrift is broken in many ways. It allows importing definitions from other services but fails to generate working code in such a scenario, so you can forget about having structs or typedefs that you want to use for multiple services.
Next, it includes type specifiers for fields and return values but don't expect any type checking. Those specifiers exist purely for marshalling/unmarshalling hints. The only "help" you get is when the runtime throws ugly exceptions that you, an experienced senior engineer, can comprehend to be due to datatype mismatches.
On the PHP side, it does something super brilliant. It IGNORES namespaces! WTF! So, you can't call out to two services that, God forbid, define classes (Thrift structs) with the same name. Class redef error. Oops!
Next, Thrift totally doesn't allow you to write services in a layered manner. E.g. You want your service to have a request validation layer that verifies a signature, strips it and passes the remaining data on to the next layer that, perhaps, does some quota checks or logging, strips more of its book-keeping data and passes the rest to the implementation.
Super easy with HTTP REST, right? Nawt so with Thrift. Muddle each and every end-point's signature for each service with parameters it doesn't even want to know of. I can't imagine writing services this way. It's sheer sadomasochism.
Last nail in Thrift's coffin is custom client and server code for each service. How 1980s is that? I had just two services to deal with and one client for that service and I was driven crazy to my wit's end trying to keep things in sync.
Experience teaches people a lot about some things. Some learning is supposed to be transient and some persistent. It's good to keep checking on the validity of your beliefs once in a while. I did it once with Java when I joined Hadoop. Indeed Java turned out to be a programming philosophy unto itself. One that was all about constraints, inflexibility and programming equivalent of the tunnel vision syndrome.
I did it again with Thrift, this time revalidating what the title of this post says. Data wants freedom. It does not need to be tied to programming language constructs. Exchanging data as objects is bad juju.
Even in the scope of the same language, passing PODs (strings, numbers, arrays, dicts) brings immense flexibility. So much flexibility that the trade-off against type safety is easy to go for. I've been programming without type safety for over 5 years now and except for the first couple of months, I never missed it.
The day you realise that an object is just a dictionary in essence, and that methods can be invoked by their names represented as strings, you'll reach a new state of programming mindset. Or maybe not, but at least I did.
Thrift is broken in many ways. It allows importing definitions from other services but fails to generate working code in such a scenario, so you can forget about having structs or typedefs that you want to use for multiple services.
Next, it includes type specifiers for fields and return values but don't expect any type checking. Those specifiers exist purely for marshalling/unmarshalling hints. The only "help" you get is when the runtime throws ugly exceptions that you, an experienced senior engineer, can comprehend to be due to datatype mismatches.
On the PHP side, it does something super brilliant. It IGNORES namespaces! WTF! So, you can't call out to two services that, God forbid, define classes (Thrift structs) with the same name. Class redef error. Oops!
Next, Thrift totally doesn't allow you to write services in a layered manner. E.g. You want your service to have a request validation layer that verifies a signature, strips it and passes the remaining data on to the next layer that, perhaps, does some quota checks or logging, strips more of its book-keeping data and passes the rest to the implementation.
Super easy with HTTP REST, right? Nawt so with Thrift. Muddle each and every end-point's signature for each service with parameters it doesn't even want to know of. I can't imagine writing services this way. It's sheer sadomasochism.
Last nail in Thrift's coffin is custom client and server code for each service. How 1980s is that? I had just two services to deal with and one client for that service and I was driven crazy to my wit's end trying to keep things in sync.
Experience teaches people a lot about some things. Some learning is supposed to be transient and some persistent. It's good to keep checking on the validity of your beliefs once in a while. I did it once with Java when I joined Hadoop. Indeed Java turned out to be a programming philosophy unto itself. One that was all about constraints, inflexibility and programming equivalent of the tunnel vision syndrome.
I did it again with Thrift, this time revalidating what the title of this post says. Data wants freedom. It does not need to be tied to programming language constructs. Exchanging data as objects is bad juju.
Even in the scope of the same language, passing PODs (strings, numbers, arrays, dicts) brings immense flexibility. So much flexibility that the trade-off against type safety is easy to go for. I've been programming without type safety for over 5 years now and except for the first couple of months, I never missed it.
The day you realise that an object is just a dictionary in essence, and that methods can be invoked by their names represented as strings, you'll reach a new state of programming mindset. Or maybe not, but at least I did.