←back to thread

The Grug Brained Developer (2022)

(grugbrain.dev)
1087 points smartmic | 5 comments | 17 Jun 25 20:24 UTC | HN request time: 0.002s | source
Show context
anthomtb ◴[17 Jun 25 21:05 UTC] No.44303941[source]▶
So many gems in here but this one about microservices is my favorite:

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

replies(8): >>44304390 #>>44304916 #>>44305299 #>>44305300 #>>44306811 #>>44306862 #>>44306886 #>>44309515 #
closeparen ◴[18 Jun 25 05:22 UTC] No.44306886[source]▶
The network boundary gives you a factoring tool that most language module systems don't: the ability for a collection of packages to cooperate internally but expose only a small API to the rest of the codebase. The fact that it's network further disciplines the modules to exchange only data (not callbacks or behaviors) which simplifies programming, and to evolve their interfaces in backwards compatible ways, which makes it possible to "hot reload" different modules at different times without blowing up.

You could probably get most of this without the literal network hop, but I haven't seen a serious attempt.

replies(2): >>44306934 #>>44308507 #
jakewins ◴[18 Jun 25 05:39 UTC] No.44306934[source]▶
Any language that offers a mechanism for libraries has formal or informal support for defining modules with public APIs?

Or maybe I’m missing what you mean - can you explain with an example an API boundary you can’t define by interfaces in Go, Java, C# etc? Or by Protocols in Python?

replies(1): >>44306951 #
closeparen ◴[18 Jun 25 05:42 UTC] No.44306951{3}[source]▶
The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the microservices architecture's perspective, the whole thing is one module with only a few methods.
replies(1): >>44307305 #
1. rcxdude ◴[18 Jun 25 06:56 UTC] No.44307305{4}[source]▶
But why would users of the module care about the dependency packages? You could still have a module with only a few methods and that's the interface.
replies(2): >>44309115 #>>44310300 #
2. dijksterhuis ◴[18 Jun 25 12:01 UTC] No.44309115[source]▶
i’ve seen devs do stuff like this (heavily simplified example)

    from submodule import pandas
why? no idea. but they’ve done it. and it’s horrifying as it’s usually not done once.

microservices putting a network call in on the factoring is a feature in this case, not a bug. it’s a physical blocker stopping devs doing stuff like that. it’s the one thing i don’t agree with grug on.

HOWEVER — it’s only a useful club if you use it well. and most of the time it’s used because of expectations of shiny rocks, putting statements about microservices in the company website, big brain dev making more big brain resume.

replies(1): >>44309767 #
3. jakewins ◴[18 Jun 25 13:35 UTC] No.44309767[source]▶
True - but most languages make it much easier than Python to disallow this kind of accidental public API creation. Python inverts the public API thing - in most (all?) other mainstream languages I can think of you need to explicitly export the parts of your module you want to be public API.

You can do this in Python as well, but it does involve a bit of care; I like the pattern of a module named “internal” that has the bulk of the modules code in it, and a small public api.py or similar that explicitly exposes the public bits, like an informal version of the compiler-enforced pattern for this in Go

4. closeparen ◴[18 Jun 25 14:37 UTC] No.44310300[source]▶
If “everyone would just” restrict themselves to import only the package you meant to public API, sure, it would work. But everyone will not just.
replies(1): >>44323485 #
5. rcxdude ◴[19 Jun 25 23:33 UTC] No.44323485[source]▶
I'm not sure why you would bother, though. If you need the package, just import it directly, no? (besides, in many languages you can't even do that kind of thing)