Hi Jeff Once you go down the hole of writing wrappers for serialized types, you'll never come back -- the new type will be used repeatedly and you'll forever need to maintain a serialization wrapper API around your business services, which in very many cases is unnecessary -- the business service, in very many cases simply implements a client-facing interface, but deals with many of the same identical APIs and types. To me, this pretty much ignores the major benefit of thrift: 1 interface for a service, not many.
The Swift API from Facebook provides a method to plugin coercions to perform serialization between any (JVM) type and a thrift IDL compatible representation (that it outputs) -- our serialized types are directly our nicely Spring/Jackson/... annotated Java and Scala business layer objects, and our client API interfaces is a strict subject of out business classes' interface. For us, this has avoided a lot of copy and paste and "same same API but different (in confusing ways)". We define an interface in scala, implement the API, and the rest is automated, including the IDL. If you're careful and define your various interfaces for different clients (eg. ClientV0Interace, ClientV1Interace, UnitTestInterace, DataBackendInterface ... ), to serve as views to a single service class implementation, this approach minimizes coding boilerplate (there is often none), and still leaves open the possibility to trivially insert an intermediate translation layer *if* that ever become necessary. This avoids the -- "not invented here so I'll make a wrapper to isolate myself from each and every API we interact with in case there are future unforeseen needs -- and lots of coding feel like progress" syndrome that I see a lot and, and that thrift helps to eliminate. ... just my two cents. I have a fork here which demos serialization of scala classes, scala containers and also can be used to marshall builtin and user-defined (i.e. not IDL generated) Java types. https://github.com/stuz5000/swift - Stu On Wed, Sep 9, 2015 at 4:31 AM, Jeff Nelson <[email protected]> wrote: > If you want to present your Thrift API directly to users, then you'll > probably need to create some struct that encompasses the information you > need for DateTime and Decimal. I'd go with a struct over a typedef because > the former gives you room to evolve in the future if necessary. > > With that said, I highly recommend that you DON'T expose your Thrift API > directly to users. Thrift is a GREAT framework for generating rpc code in > many languages, but it has to support the lowest common denominator of > languages features so that means it feels clunky and unnatural in most > languages. In the early days, Cassandra exposed their Thrift API directly > to users and it didn't work out well. > > Instead, I recommend that you wrap your Thrift API in language specific > drivers. This will allow you to give users libraries that feel natural and > adhere to the best practices of the language they choose. Additionally, > this means that you can have logic that automatically converts whatever is > the canonical DateTime class in each language to the thrift struct you're > expecting on the server. > > This approach has worked really well for ConcourseDB > <https://github.com/cinchapi/concourse>. For developing the language > drivers, thrift makes it so that we don't have to worry about the RPC stack > at all. We simply focus on the business logic of the driver (which is > generally the same across languages...just mapping various types to the > appropriate Thrift API calls). And our users benefit greatly because they > don't need to know about Thrift at all (this greatly reduces the barrier to > entry). We're also future proofed in case we ever want to swap out thrift > in the future (though I highly doubt we'd do that because thrift is > awesome). > > Cheers, > Jeff > > > > On Tue, Sep 8, 2015 at 10:12 PM, David Bennett <[email protected]> wrote: > >> In order to use Thrift as a remoting API for Andl I have to provide support >> for two data types: DateTime and Decimal. The question is what strategy to >> use that will produce the best outcome across common client languages. >> >> The DateTime data type is yyyy-mm-dd hh:mm:ss.xxx. It can use a wire format >> of i64 (100nsec units since Gregorian 0000, faster) or ISO-8601 (slower). >> >> The Decimal data type is (at least) 24 decimal digits of precision. It can >> use a wire format of 2*i64 (special format, faster) or a string (slower). >> >> The question is not about wire formats but how best to define and implement >> these types in Thrift for easiest consumption by client software in various >> languages. >> >> Is a typedef a useful approach? Or a named struct with a single field? >> >> How does one make it easy for the client to consume (given that most >> languages have some kind of preferred type)? >> >> Regards >> David M Bennett FACS >> >> Andl - A New Database Language - andl.org >> >> >>
