Abstraction is not very compatible with concurrency, so as well as your your beautiful abstract API, you also need some ‘cut through the layers’ functions to return the underlying classes you need to synchronise on. Now you have a right mess that’s incredibly hard to understand, infuriating to debug, and impossible to refactor. Best you can do is put another layer of abstraction on top. Repeat every six months.
Yeah, well-designed abstraction can help enable more concurrency. That said, concurrency isn’t easy at any point once there’s shared data that needs to be written to during the process. Maybe it’s not so bad if your language has good concurrency support (like monitor classes and such that handle most of the locking behind the scenes), but even then, there’s subtle pitfalls that can add rare bugs or crashes to your program.
Abstraction is not very compatible with concurrency, so as well as your your beautiful abstract API, you also need some ‘cut through the layers’ functions to return the underlying classes you need to synchronise on. Now you have a right mess that’s incredibly hard to understand, infuriating to debug, and impossible to refactor. Best you can do is put another layer of abstraction on top. Repeat every six months.
That’s just bad interface… When you design an API as if operations were independent, but they aren’t, you run into these issues.
Don’t add “cut through the lawyers” functions, fix your interface.
Yeah, well-designed abstraction can help enable more concurrency. That said, concurrency isn’t easy at any point once there’s shared data that needs to be written to during the process. Maybe it’s not so bad if your language has good concurrency support (like monitor classes and such that handle most of the locking behind the scenes), but even then, there’s subtle pitfalls that can add rare bugs or crashes to your program.
Pack it to lambda and name it microservice.