Am Samstag, 14. Juni 2014 18:24:34 UTC+2 schrieb rkuhn: > > 13 jun 2014 kl. 08:27 skrev Carsten Saathoff <[email protected] > <javascript:>>: > Am Freitag, 13. Juni 2014 07:39:15 UTC+2 schrieb Evan Chan: >> >> On Wednesday, June 11, 2014 2:35:27 AM UTC-7, Carsten Saathoff wrote: >>> >>> And there is another aspect. Especially for larger projects >>> microservices are great to "enforce" a share nothing philosophy. Using akka >>> serialization, I either have to share the messages or use protobuf + code >>> generation, which is again more complicated. I am not sure whether that can >>> be achieved with CBOR standard you mentioned, but using JSON via HTTP has >>> the advantage that I don't have to share code while it's still very easy to >>> use. >>> >> >> I think the "JSON means you don't have to share code" is a bit false. >> Everywhere that uses the JSON interface, especially if it is a compiled >> language like Java or Scala, is going to need quite a bit of scaffolding, >> most likely a client, and serialization/deserialization code to work with >> that REST API. If you really stick by the "shared nothing", this >> significant chunk of code must be duplicated, leading to errors and a >> maintenance nightmare. It is true that with Akka case classes you _must_ >> share the code, but I would say in practice this is far easier than having >> to set up clients and deser code at every client service. >> > > I think what you share is the API. Depending on how complicated the API > is, it might be absolutely feasible to duplicate the API layer but gain > decoupling. With all the good JSON and HTTP libs, writing such a layer is > rather easy. I think decoupling of (micro)services is extremely important, > and using the same set of case classes means you have an code-level > dependency. Using case classes everywhere also means that integrating a > service written in another language will be more complicated. But having > the freedom to try out new stuff is another big advantage of microservices. > > So, don't get me wrong, I am not proposing everything should exclusively > communicate via HTTP and JSON, but when we are talking about a microservice > platform, I think decoupling of services also on the code level is an > extremely important aspect. And I am also aware that HTTP+JSON are not very > efficient, so that a more compact alternative such as CBOR sounds like a > good idea. And ultimatively, this should probably be configurable, such > that in projects where sharing of messages and API code is required, this > can be done as well. > > > This goes in the same direction I am currently exploring: instead of > agreeing on the case classes (which means agreeing on fully-qualified class > names) we could switch to a more structural approach, meaning that the > message itself consists of data that can be parsed without knowing the > schema. The recipient can then decide how to respond by querying that > structure and extracting what it needs or understands. The gain is that > interoperability between different platforms or segregated parts or a > larger application or different versions of the same services becomes a lot > easier than today. Of course the right content needs to arrive at the right > place, but all incidental baggage (like the color of the parcel > wrapping—the FQCN) is removed. > > RESTful APIs clearly are the inspiration for this line of thinking; are > there any fundamental downsides to this approach? >
Except what Evan mentioned, I don't think so. I assume it is important to provide a good (de)serialization library. Currently, sending a case class from Actor System A to B is a no-brainer. Probably it will get a bit more complicated when using a more structural approach, since you have to do some manual parsing. So that should be made as simple as possible. I think the other important question is, how do I address a uniservice, and will stuff like automatic failover, loadbalancing etc. be possible in some standardized way? best Carsten -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
