I stumbled across an interesting post recently, and a friend also shared it with me. While this blog will mostly focus on Javascript, most of my experience is on the back end.
Miguel Gonzalez writes a short but meaty post on what to look out for when doing messaging. I want to highlight a couple of his points, because I’ve got a few thoughts on them.
1. Don’t implement complex business logic in event handlers. — This one is fairly straightforward, but important. An event handler should do one thing. Either handle an event (email, save to database, etc.), or contain an if statement to generate another command.
2. Don’t use heavy messages with lots of properties. — This one is a little more interesting. I’ve actually implemented a heavy message just to get the initial data going (such as a create <something> message). I think he’s right, and a better way to do this sort of thing is just to use a RESTful POST. I have been pondering this issue on my own and it seems like it’s easier to just implement commands using REST and skip the messaging altogether. To me, commands tend to be more synchronous, anyway, because the client really needs to know what happened, so the user can know something went wrong.
It sounds like Miguel is describing something that’s neither a command nor an event, so I’m guessing he’d want to skip messaging altogether as well, but I may be wrong.
3. Don’t write generic command handlers with business logic. — I like this one a lot. In the past I’ve had a tendency to want to use inheritance or some crazy generic handling pattern when you really need to split it out. Anything that’s common put in a common or utils function. Use the simpler parts of programming languages to abstract out: re-use functions. Don’t create crazy generic code. It’s hard to reason about.
javascriptbeach 