clients in other languages

From the looks of things most of the code is GRPC code generated.

Would be cool to setup a docker to make the code for java, nodejs, Dart, etc.
Then i am guessing some people that use that language can write the extra code needed by looking at how simple it is in the golang code.

I think the Dart one would be pretty easy as i have done some GRPC with Dart. That would make Liftbridge work with Flutter.

Just noticed a ruby one:https://github.com/andyl/liftbridge_ruby

is there an Awesome Liftbridge list anywhere?

[tylertreat]

Yeah, more language clients are on my radar, just haven't gotten to it yet (plus there's a lot of server stuff to do). I plan to do a Python and Java client next if someone else doesn't get to it first. Dart would be great too. Generating the gRPC code is actually very straightforward, I just need to get it properly documented. And like you said, there is pretty minimal code on top of what's provided by gRPC.

[canadaduane]

Is there a nodejs client?

[tylertreat]

Not at the moment, sorry. Generating the gRPC bindings give you a low-level client though.

https://github.com/liftbridge-io/liftbridge-grpc

I haven't had time to document this yet.

[joeblew99]

@tylertreat

Saw the python client and his notes about what extra code a client needs apart from grpc.
Maybe its getting to the point that a MarkDown can be put on the main repo for client implementers to get an idea of the effort ?

https://github.com/dgzlopes/python-liftbridge#how-to-contribute

[tylertreat]

@joeblew99 Agreed, I think it's to the point where we can document the steps for creating a client library. I'm planning to merge this this week which implements stream partitioning (and should be the last major API change before a stable release). Once this is merged I'll add some markdown detailing what's needed to implement a client. Maybe @dgzlopes can provide some input based on his work with the Python client.

[joeblew99]

Wow exciting. Looks like it might finally be ready for action. I am planning to put a web gateway on top to make it easy to build front-end. https://github.com/dunglas/mercure https://gitlab.com/wallforfry/dart_mercure The way it works is to use SSE to push updates to front ends Anyways just figured it is worth mentioning.

…

On Wed, 28 Aug 2019, 17:28 Tyler Treat, ***@***.***> wrote: @joeblew99 <https://github.com/joeblew99> Agreed, I think it's to the point where we can document the steps for creating a client library. I'm planning to merge this <liftbridge-io/liftbridge#93> this week which implements stream partitioning (and should be the last major API change before a stable release). Once this is merged I'll add some markdown detailing what's needed to implement a client. Maybe @dgzlopes <https://github.com/dgzlopes> can provide some input based on his work with the Python client. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11?email_source=notifications&email_token=AC3RU45RDFHMBI2V6EOW3ULQG2KQJA5CNFSM4HNM7ONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5LQM6A#issuecomment-525796984>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC3RU46YKB5CSFTKWW5DO7DQG2KQJANCNFSM4HNM7ONA> .

[paambaati]

@tylertreat I’d love to build a Node.js client!

A quick note — it would be help if there were releases with changelogs so we could start tracking changes.

[tylertreat]

Yeah, I plan to start doing releases now that there shouldn't be any more breaking changes to the API. Will definitely include changelogs.

[paambaati]

@tylertreat Sounds great! I've started work on the Node.js client (not public yet), but I've run into some issues (specifically, a code 13 "failed to parse server response" error). What would be a good place to ask for help?

EDIT

I have a repro now —

1. docker run -p 4222:4222 -ti nats:latest --debug --trace in a window.
2. go get github.com/liftbridge-io/go-liftbridge and then $GOPATH/bin/liftbridge --raft-bootstrap-seed --nats-servers nats://localhost:4222 --level debug in another window.
3. Clone my repo from https://github.com/paambaati/node-liftbridge.git in yet another window.
   1. yarn install or npm install
   2. yarn run debug or npm run debug

The debug script attempts to create a new stream, then publish a few messages, then subscribes to the same stream (subject) and then publishes a few more messages.

Expected output — Each published message should be printed to console (see relevant line).

Actual output —

Error: 13 INTERNAL: Failed to parse server response
    at Object.exports.createStatusError (~/node-liftbridge/node_modules/grpc/src/common.js:91:15)
    at ClientReadableStream._emitStatusIfDone (~/node-liftbridge/node_modules/grpc/src/client.js:233:26)
    at ClientReadableStream._receiveStatus (~/node-liftbridge/node_modules/grpc/src/client.js:211:8)
    at Object.onReceiveStatus (~/node-liftbridge/node_modules/grpc/src/client_interceptors.js:1272:15)
    at InterceptingListener._callNext (~/node-liftbridge/node_modules/grpc/src/client_interceptors.js:568:42)
    at InterceptingListener.onReceiveStatus (~/node-liftbridge/node_modules/grpc/src/client_interceptors.js:618:8)
    at ~/node-liftbridge/node_modules/grpc/src/client_interceptors.js:1029:24 {
  code: 13,
  metadata: undefined,
  details: 'Failed to parse server response'
}

[tylertreat]

@paambaati It looks like it's failing on subscribe? I bet it's because Liftbridge first sends an empty message on the stream when a subscription is successfully created (or an error if not). Are you handling this case in the client? See the Go client for an example:

go-liftbridge/client.go

Lines 591 to 593 in 6fbf530

	// The server will either send an empty message, indicating the
	// subscription was successfully created, or an error.
	_, err = st.Recv()

[paambaati]

Liftbridge first sends an empty message on the stream

I’m assuming that empty message conforms to the proto.

@tylertreat My initial guess is the response couldn’t be parsed by gRPC, and hence the error code 13 (it is reserved only for serious errors).

I’m gonna debug this externally with tools and see if I’m able to reproduce this.

[tylertreat]

I’m assuming that empty message conforms to the proto.

Yes, it is a normal proto message, so I'm not sure why you'd be hitting a parse error. I will see if I can spend some time looking at it today.

[paambaati]

@tylertreat After studying the Go client implementation more closely, I’ve also realized there’s a lot more I’ve yet to implement (for example, partitioners) and things I haven’t fully understood (like subjects and how they can have a .<partition> notation). I’m gonna pause work on the Node.js client I can understand the client semantics more.

Documentation about the key operations (publish, subscribe, fetch metadata, etc.) and how to implement clients would be super-helpful. If there’s a branch where they’re being worked on, I’ll be more than happy to contribute. I’m currently grokking more of the Go client codebase and plan to write down my version of a “How to write a Liftbridge client” too.

[tylertreat]

Yep, I'm planning to write up a guide on implementing a client later this week. Partitioning was just merged. The client doesn't actually have to support it to start using Liftbridge since when you create a stream it consists of just a single partition by default, so publish and subscribe work as normal without a partitioner.

[paambaati]

when you create a stream it consists of just a single partition by default

A-ha! I didn’t know this. Would be great if the documentation also marked the fields as mandatory or optional.