Hacker News Reader

Comment by tel | Hacker News Reader

The scariest thing mentioned here is when Team Email switches from a Service Object to a Micro Service. Actually, it's not that scary as part of email where the user of that object always anticipates potential failure (and probably has next to no recourse if failure occurs).

So instead we could pretend that it's something like MachineLearningProvider. When this converts to a Micro Service its failure space increases by an order of magnitude without expressing it in the interface.

That was the primary problem with RPC—you really don't want to confuse local function calls from remote ones.

View on HN

This is generally solved with monadic design. Results are returned wrapped in some monad - Future[Result] in this case. The monad generally expresses the failure modes.

When you switch from, e.g. `LocalMachineLearningProvider` to `RemoteMachineLearningProvider`, your interface will change from MachineLearningResult to Future[MachineLearningResult].

And then instead of mostly working (when the network isn't down), your code fails to compile and doesn't work at all. And you have to either spend just as much time reworking things to handle the errors in a user-acceptable manner, or take shortcuts and stub out the error handling to either die or fake things and keep going (ie, to mostly work as long as the network isn't down).

Certainly, or even with two layers of futures. Notably, this changes the interface.

I'm not saying it's not solvable, just that it was so silently mentioned in the article. You should have to work to reproof your code after RPCing something.

It can just be scary if you've spent time making it out as though MchineLearningProvider can never fail. Interacting with an outside object can be a painful experience.

This gives you some of the worries of a true distributed system within your monolith.

If only there were a way of transforming F[F[X]] to F[X]. Then we could avoid nested futures!

Especially if it had some nice syntax sugar. Then we could chain together as many as we want!

You're being sarcastic, but I meant to suggest that there would be value in running those layers independently so that you don't combine errors. If you present it as F[X] then you've thrown away potentially interesting information. IO (IO ()) is pretty valuable, for instance.

Just curious, what is the advantage? Near as I can tell EmailProvider will return one of two sorts of errors - either a ServiceError (the microservice was unable to send) or a NetworkError (unable to talk to micro service). These will be represented in the class of the exception the future wraps.

What benefit does two levels of futures provide? I was sarcastic before, but now I'm honestly asking.

The two differences I can think of are

    1. If you don't assume exception throwing (which
       may be valuable) then you can more easily distinguish
       one failure from the other.
    2. It reflects in the type a more accurate representation
       of the effect going on. If such distinctions are
       undesirable it's a trivial `join` to eliminate them
       but if the distinction is never exposed then you can't
       get it back.

So really, my thought is that given greater opportunity to distinguish between end-user meaningful effects it's worth exposing them by default. It should be a deliberate choice to hide them with join.

Tel I have no idea why, but your reply is dead. It is a good answer, however, and provides me with food for thought.

Strange. I see it appearing twice. I will try deleting one.

> When this converts to a Micro Service its failure space increases by an order of magnitude without expressing it in the interface.

I think you just emphasized a bit that, in principle, should never be allowed to happen. When Team Email switches to a service their interface has changed, period. In some idealized sense the contract they implement is the same, sure, but an interface that allows for the possibility of timeouts, down servers, lost packets, etc. is fundamentally different from one that doesn't, and you can't (or at least shouldn't) use the same code to interact with the two. Ideally, the compiler wouldn't even let you try - and in a good type-safe language, this is accomplished if Team Email swaps out the interface they're implementing when they go service.

Oh totally agreed! I was bothered that the essay emphasized doing this without "changing the interface"! At least not the types.

So you are sugessting better prematurely "optimizing" every call to be remote from the beginnig? Wouldnt anyone wrap remote services behind a facade anyways instead of directly calling a http client? I fail to see how this leads to an interface that expresses the remoteness more in most of the cases.

I'm suggesting that you can't always abstract away things the way you'd like. The idea of how to send an email is highly abstractable, the idea of some other entity doing it leaks and rightly should.

Reply on news.ycombinator.com