5 ms·

>because there's no way to send complex structures across service boundaries; you end up spending more effort serializing and deserializing than actually doing

>because there's no way to send complex structures across service boundaries; you end up spending more effort serializing and deserializing than actually doing business logic. Honest question, have you ever actually worked with decently written micro-services? You don't send complicated objects, you send relatively simple objects. And you don't do it by hand, grpc and thrift have existed for a long time. I'd argue that part of good decoupling, in functional or micro-services programming, is making sure you only communicate simple objects around.

lmm 7y ago
> Honest question, have you ever actually worked with decently written micro-services? As decently as is possible, yes. > You don't send complicated objects, you send relatively simple objects. Right, which limits how powerful the overall system you can build is. That was my whole point. > And you don't do it by hand, grpc and thrift have existed for a long time. Sure, but they have pretty anaemic type systems and a lot of stuff is just inherently high-effort to serialize (see the recent post about defunctionalising the continuation). > I'd argue that part of good decoupling, in functional or micro-services programming, is making sure you only communicate simple objects around. Functional programming gives you more tools to interleave complicated constructions while still enforcing that all your concerns are treated orthogonally. For example you can form a free monad structure that contains commands that will be interpreted by one particular service, but interleaved with other computations that will be implemented by other services or directly. The types ensure that everything's properly decoupled, but you can still represent all the complexity that's there in the actual problem. You can't do that with microservices.

5 ms·

>because there's no way to send complex structures across service boundaries; you end up spending more effort serializing and deserializing than actually doing

by marcinzm 7y ago

lmm 7y ago
> Honest question, have you ever actually worked with decently written micro-services? As decently as is possible, yes. > You don't send complicated objects, you send relatively simple objects. Right, which limits how powerful the overall system you can build is. That was my whole point. > And you don't do it by hand, grpc and thrift have existed for a long time. Sure, but they have pretty anaemic type systems and a lot of stuff is just inherently high-effort to serialize (see the recent post about defunctionalising the continuation). > I'd argue that part of good decoupling, in functional or micro-services programming, is making sure you only communicate simple objects around. Functional programming gives you more tools to interleave complicated constructions while still enforcing that all your concerns are treated orthogonally. For example you can form a free monad structure that contains commands that will be interpreted by one particular service, but interleaved with other computations that will be implemented by other services or directly. The types ensure that everything's properly decoupled, but you can still represent all the complexity that's there in the actual problem. You can't do that with microservices.