Drb Alternatives

drb reviews and mentions

• Ruby Built-In Hash Persistence
  5 projects | news.ycombinator.com | 20 Sep 2022

  I recently had the need to build an internal testing system that distributed workloads across many workers via a client/server model. I did the proof-of-concept using druby [1] and it turned out to be so simple and stable that we just ran with it. It'd been years since I had used that library and instinctively I assumed we'd get the poc out and then rebuild it using some sort of web service and utilize a high concurrency web server but druby just worked!

  [1] https://github.com/ruby/drb

• How Did REST Come to Mean the Opposite of REST?
  2 projects | news.ycombinator.com | 18 Jul 2022

  > Not really, there is information_shema where they get everything they need to know about structure separately from data.

  information_schema only includes standardized information about standard SQL features. It doesn't expose DBMS-specific features like PG's comments; let alone give you not-standardized info on things that are part of the standard, e.g. any DDL-equivalent machine-accessible representation for views or procedures or types or domains. Gathering all of that stuff requires carefully joining five or ten different DBMS-specific tables together. Some of it even requires feature negotiation + graceful degradation.

  > Yes. Awful. Do we want all APIs to be like that? Why?

  Because then everything other than the well-known root can be changed freely without breaking the client.

  Compare-and-contrast: remote object brokers in dynamic languages, e.g. Ruby's https://github.com/ruby/drb. There are module functions that serve as well-known roots to the APIs you're remoting against; but as soon as you get an object handle, everything from that point forward is the result of sending a proxy-object (opaque API) a message, and getting a handle to a new object passed back in return. Where that new object might actually be an object-handle to an object on a different system than the one you first connected to.

  If you write a client to talk to such a remote system the way it's intended (i.e. by making OOP-style call-chains, and holding onto object-handles you want to reuse), then there's very little that should be able to break your client library, besides a fundamental change in the semantics of what the remote service delivers. Your client library isn't making assumptions — it's being told what the possibilities are at each step, like a browser is/does.

  Also, the other thing you get is: anyone with a web browser can use your API, because your API is, in a certain sense, "a website." Like how anyone can interact with S3 by just visiting the URL of an object.

  > HTML is unsuitable for machine-to-machine communication

  Who said? Someone back in 2005, when every language in common use didn't have HTML-parsing libraries?

  HTML needs conventional microformats to specify the abstract types of otherwise-text data... but so does JSON. JSON gives you text and numbers, but it doesn't give you ADTs like you'd get from e.g. Avro / Protobufs / etc. You still need a schema on top of JSON to get anywhere. So what are you really getting from JSON that you don't get from having your XHR responses be HTML webpage that were designed to be highly machine legible?

• Ruby background processing worker error handling comparison
  1 project | dev.to | 6 Aug 2021

  A word about Belated: it runs in a different process, but uses dRuby to connect your main app and Belated.

• A note from our sponsor - InfluxDB
  www.influxdata.com | 3 May 2024

  Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →