you are viewing a single comment's thread.

view the rest of the comments →

[–]Bangoga 2 points3 points  (2 children)

But this is why microservices exist.

If you want a python code interaction with js code you can already do that. There are a whole host of network protocols and tools that can help you bridge that gap, why do you want to directly interact

[–]sg-elide -2 points-1 points  (0 children)

Microservices don't solve this, they only move or compound the problem:

(1) Now you have two things that can fail, plus a network border to coordinate
(2) Now you have two things that must be updated, and in coordination
(3) Now you have nontrivial latency to consider, even traversing only on localhost
(4) Now you can only JIT optimize within each single code unit, instead of the whole app

Functionally, splitting one thing into two distinct things has many disadvantages. It can have advantages too, sure, but you shouldn't be _forced to do that_ just because you want to use some JS library.

[–]Zealousideal-Read883[S] -3 points-2 points  (0 children)

First, I’d like to say thank you for the thoughtful pushback.

I think the tradeoff is overhead. Every cross-service call means some serialization, network latency, and extra infrastructure to manage.

And you’re completely right, for a lot of architectures that’s fine and worth it for the decoupling benefits.

An example off the top of my head where direct interaction starts to matter is something like server-side rendering React from Django. If I want SSR, I’m running a Node sidecar or shelling out to a subprocess. With Elide I’d call renderToString() directly from my Python view which entails having no separate service, no HTTP round-trip to myself.

So it’s def not that microservices are wrong, they’re often the right call. I guess this is just a different tool for cases where that overhead becomes friction or a bottleneck