It's TCP vs. RPC All over Again

Re:It's TCP vs. RPC All over Again by cryptonector on Wednesday February 22, 2023 @03:57PM (#34902608)

There's several ways of doing service discovery for HTTP services like this in an enterprise, using 3xx replies to redirect if you move the service. The simplest is to just use a URI authority that you can change as needed. The next simplest is to publish URI RRs in DNS. The next simplest is to use the .well-known URI local-part namespace to include information for client-side routing. Granted, the last two are recent developments.

[ Parent | on HN ]

Re:It's TCP vs. RPC All over Again by vidarh on Wednesday February 22, 2023 @05:21PM (#34903800)

Or we could just use DNS A or CNAME records and not have to do any of those, the way e.g. CoreDNS w/k8s or ldapdns on top of openldap, and similar does.

There are use cases for more complicated service discovery, especially discovery of external services, but for the scenario I described, which in involved discovery within our own network this all just would have added extra complexity for no benefit that would have made any difference to us.

Note that service discovery was not listed as one of the reasons I think http doesn't solve the issues that made us choose a mail server back then..the exact same service discovery mechanism would have worked just fine for http too. But we'd still have had to build all the message broker code from scratch instead of picking and choosing from pre-existing components.

[ Parent | on HN ]

Re:It's TCP vs. RPC All over Again by cryptonector on Wednesday February 22, 2023 @05:52PM (#34904198)

I'm not saying that you shouldn't have used SMTP. It really is appropriate for this sort of thing. If you wanted an HTTP interface you might still make it inject messages into SMTP, with HTTP being only used for a browser UI, say, or with the HTTP server as a proxy for some reason.

My objection had been to LDAP. LDAP is too heavy-weight by comparison to HTTP w/ a JSON API.

[ Parent | on HN ]