Re:Slack’s Migration to a Cellular Architecture
by skullone on Saturday August 26, 2023 @02:30PM
(#37275543)
Man what a mess. Meanwhile, everyone else can extend a library used by their common services in a common language trivially.
Re:Slack’s Migration to a Cellular Architecture
by rs_rs_rs_rs_rs on Saturday August 26, 2023 @02:36PM
(#37275597)
Let me guess, they should rewrite everything in Javascript?
Re:Slack’s Migration to a Cellular Architecture
by skullone on Saturday August 26, 2023 @02:40PM
(#37275641)
Woe is us if they actually did.
Re:Slack’s Migration to a Cellular Architecture
by tomrod on Saturday August 26, 2023 @02:58PM
(#37275819)
Nah, Excel. /s
Re:Slack’s Migration to a Cellular Architecture
by wmf on Saturday August 26, 2023 @02:51PM
(#37275750)
Almost everyone embraced polyglotism and microservices together.
Re:Slack’s Migration to a Cellular Architecture
by hotnfresh on Saturday August 26, 2023 @03:24PM
(#37276004)
Meh. As long as you’ve got a good, typed interface for passing messages between them and for having a common understanding of (and versioning system for) key data structures, that’s fine for this sort of thing where it’s largely processing steams of small messages and events.
… but it’s probably JSON and some JSON-Schema-based “now you have two problems” junk instead of what I described. In which case, yeah, ew, gross. Unless they’ve made some unusually good choices.
Re:Slack’s Migration to a Cellular Architecture
by nostrebored on Saturday August 26, 2023 @04:21PM
(#37276512)
There are tons of approaches to align on service contracts for JSON based API calls. There’s also libraries like gRPC which help make contacts explicit. Neither are really uncommon
>Slack does not share a common codebase or even runtime; services in the user-facing request path are written in Hack, Go, Java, and C++.