4 ms·

If you're more worried about connection and discovery semantics, you'd want to use Datawire Connect which is built on top of Quark. Quark is being used by compa

by rdli 11y ago

If you're more worried about connection and discovery semantics, you'd want to use Datawire Connect which is built on top of Quark. Quark is being used by companies that for one reason or another need/want to build their own protocol. This is admittedly overkill for most people. Datawire Connect integrates discovery as well as connection semantics (next week we'll have a release that supports full Hystrix semantics, e.g., circuit breakers and timeouts and load balancing).

lobster_johnson 11y ago
Looks interesting. As with Quark, I think we'd hve to wait until you have reached a higher level of maturity and a broader selection of languages. We need at least Go, Ruby and Node.js to get going, which is what our current apps our built with. We're also evaluating Elixir and Swift as possible future languages.
- rdli 11y ago
  Great feedback! We will have Ruby in a few weeks (code is sitting on a GitHub branch), and we have Node already. Go is on the roadmap, but we also have a proxy that lets you interface with languages we don't support natively. I'd be super interested in what tech you find that works well with your language set of Go, Ruby, and NodeJS. GRPC won't. Thrift might (don't know offhand). NATS might, but there's lots of coding there you need as you mention and it's a SPOF.
  - lobster_johnson 11y ago
    gRPC does have native bindings for all of Go, Ruby and Node.js. Not sure why you say it won't work well? NATS being a SPOF isn't necessarily a problem for us if it's stable, which it seems to be. We are already completely dependent on HAProxy as a SPOF, anyway. Moreover, most client bindings seem to support providing a host list they use for failover. I will take a closer look at Quark and Datawire Connect when I have a spare moment. Do you have it running in production? Happy to hear that Go is on the roadmap.
    - rdli 11y ago
      gRPC bindings for languages that aren't popular at Google (e.g., Ruby, Node) aren't particularly mature. Each of the different language bindings is independently maintained, so there is no guarantee of feature parity across the languages. We do not have Quark/DC running in production yet. Most of the adoption has been in the realm of testing scenarios (it's super handy to be able to generate client stubs).

by rdli 11y ago

lobster_johnson 11y ago

Looks interesting. As with Quark, I think we'd hve to wait until you have reached a higher level of maturity and a broader selection of languages. We need at least Go, Ruby and Node.js to get going, which is what our current apps our built with. We're also evaluating Elixir and Swift as possible future languages.

rdli 11y ago
Great feedback! We will have Ruby in a few weeks (code is sitting on a GitHub branch), and we have Node already. Go is on the roadmap, but we also have a proxy that lets you interface with languages we don't support natively. I'd be super interested in what tech you find that works well with your language set of Go, Ruby, and NodeJS. GRPC won't. Thrift might (don't know offhand). NATS might, but there's lots of coding there you need as you mention and it's a SPOF.
- lobster_johnson 11y ago
  gRPC does have native bindings for all of Go, Ruby and Node.js. Not sure why you say it won't work well? NATS being a SPOF isn't necessarily a problem for us if it's stable, which it seems to be. We are already completely dependent on HAProxy as a SPOF, anyway. Moreover, most client bindings seem to support providing a host list they use for failover. I will take a closer look at Quark and Datawire Connect when I have a spare moment. Do you have it running in production? Happy to hear that Go is on the roadmap.
  - rdli 11y ago
    gRPC bindings for languages that aren't popular at Google (e.g., Ruby, Node) aren't particularly mature. Each of the different language bindings is independently maintained, so there is no guarantee of feature parity across the languages. We do not have Quark/DC running in production yet. Most of the adoption has been in the realm of testing scenarios (it's super handy to be able to generate client stubs).