Closed yusefnapora closed 8 years ago
BTW, the protobuf types are missing signatures & hashes, since I just wanted to get something basic up. Also, the LSpaceServer
needs a .env
setup with orientdb url and credentials, or it'll throw on startup.
We should also probably spend a minute figuring out whether this is worth pursuing further, since there's no browser support for gRPC (according to the FAQ, which I kind of wish I'd read yesterday...)
So the way we used thrift/spindle at 4sq was this:
This is nice for a polyglot environment but definitely very complex. Also note that even at this level we weren't using binary transport.
We should try to identify exactly the properties we want from the API and consider whether using these fancy libs is required. I suspect that ad-hoc serialized JSON can probably get us quite far.
(Thrift also ends up creating a ton of legacy cruft in your definitions if there's a lot of schema changes because of how compatibility works, not sure about protobuf)
given that most of these changes are in rpc/
and Build
is unlikely to diverge a lot, I'm ok just parking this in a PR for now
This adds a subproject named
rpc
that defines some gRPC types and a simple service. The only functional method of the service islistCanonicals
, which returns a list of all canonicals in the graph.There's some awkward duplication of our domain types here; the
Types.proto
file basically redefines the various types fromio.mediachain.Types
as protobuf messages. I put some conversions to/from the gRPC types inio.mediachain.rpc.TypeConversions
, so you can say e.g.someCanonical.toRPC
to create an instance of the gRPC generated case class from aCanonical
.I also put in some definitions for
Node
,Edge
andGraph
types, but those are mostly "thinking out loud" about what a subgraph might look like encoded with protobufs.You can run the server with
sbt "project rpc" "runMain io.mediachain.rpc.LSpaceServer"
and the client withsbt "project rpc" "runMain io.mediachain.rpc.client.LSpaceClient"