Skip to content

Instantly share code, notes, and snippets.

@HelloGrayson
Created August 7, 2015 20:27
Show Gist options
  • Save HelloGrayson/84b6e947c7937084f12b to your computer and use it in GitHub Desktop.
Save HelloGrayson/84b6e947c7937084f12b to your computer and use it in GitHub Desktop.
Do we want to pull Hyperbahn specific logic into it's own client like Node & Go?
from tchannel import TChannel, Hyperbahn
tchannel = TChannel('my-service')
tchannel.listen() # or
hyperbahn = Hyperbahn(tchannel)
hyperbahn.advertise()
@HelloGrayson
Copy link
Author

@HelloGrayson
Copy link
Author

Or, with inheritance:

from tchannel import Hyperbahn

hyperbahn = Hyperbahn('my-service')
hyperbahn.advertise()

This has the benefit of representing the same public API with additional methods.

hyperbahn.raw()
hyperbahn.json()
hyperbahn.thrift()

I don't find that this abuses inheritance.

@blampe
Copy link

blampe commented Aug 7, 2015

Let's be consistent with node/go.

@HelloGrayson
Copy link
Author

I'll look more into it.

@HelloGrayson
Copy link
Author

From what I can tell, this is consistent with Go & Node:

In app.py:

from tchannel import TChannel, Hyperbahn

tchannel = TChannel('my-service')
hyperbahn = Hyperbahn(tchannel)
hyperbahn.advertise()

In endpoint.py or some service layer class:

from app import tchannel

tchannel.thrift(...)

So in summary you compose a TChannel in to a Hyperbahn and call advertise instead of listen, and then continue to use the tchannel object. I think this will work in Python since everything is a reference.

@HelloGrayson
Copy link
Author

Corbin seems to think we need to consider sub-channels, so I'll bang my head against the design a bit more so we don't get it wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment