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.

[–] Evotech@lemmy.world 2 points 6 hours ago* (last edited 6 hours ago)

That's why you build the api first. If you need to "cut through" anything you build an api for that instead.

[–] 3abas@lemmy.world 12 points 22 hours ago (1 children)

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.

[–] Buddahriffic@lemmy.world 5 points 21 hours ago

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.

[–] MrMetaKopos@slrpnk.net 15 points 23 hours ago (1 children)

[–] vane@lemmy.world 3 points 20 hours ago

Pack it to lambda and name it microservice.