justforfunc #31: gRPC Basics

preview_player
Показать описание
Let's continue where we left it in the previous episode.
After understanding the basics of protocol buffers it's time
to learn gRPC, which provides a way to define APIs on protobufs.

References:
Рекомендации по теме
Комментарии
Автор

For those wondering what was going on with the context package not being fully compatible, turns out I have an old version of the package vendored in the justforfunc repo!

JustForFunc
Автор

I have seen all of your videos in this channel (many times) and I wanna say, Thanks.
You are so good at what you do as professional.
I appreciate it.

rahidehzani
Автор

An example of generating an HTTP API​ from protobuf definitions sounds really cool!

jackmordaunt
Автор

I just started to watch your videos today (like 7 in a row) I'd love to see gRpc auth or testing as someone sugested, but all I've watched so far are great videos

ruiztulio
Автор

Yes!! Bidirectional streaming would be cool to watch

harshthakur
Автор

great stuff. gRPC was all over kubecon the past editions. it's good to find this info in video form. I am definitely interested in security around it. TLS and authentication or whatever else exists.

TheMegaMrMe
Автор

thanks a lot for your videos. Both topics you suggested at the end are very interesting for future episodes: bidirectional grpc streaming and exposing grpc as http.

maximyefremov
Автор

1) Click video
2) Click like button
3) Actually watch the video

Awesome stuff Francesc! 👍

tunedmystic
Автор

THIS IS SO EASY TO UNDERSTAND! THANK YOU!!!!

tomochaaan
Автор

Great episode as always! As Ideas for next episodes can I suggest
1 - Testing - What is a good approach for testing a client server project like this?
2 - Concurrently/Race Detection - I'm assuming that with no locking on your database file, multiple clients could easily cause corruption when adding tasks on this server? Can you use the race detector to help debug something like this? What code changes would be needed to prevent this corruption?

jamesbnz
Автор

Thanks for this information. I'm new to Go, but this process doesn't seem very Go-like, and seems to be begging for better tooling. Rather than developing the definition in the Proto Buffers IDL, it seems like it should be possible to write your remote process as a simple goroutine, and then when you want to deploy it, to generate the IDL from the interface to the goroutine's invocation, channels, and access to global variables. Then have a library call that takes in the goroutine and instead of running it locally runs it remotely. The Go language's strong point is being able to simply handle concurrency. Remote procedure calls are just concurrency running across the network. But it seems like this is just reintroducing older styles of dealing with concurrency, rather than relying on the language and run time.

richdobbs
Автор

cool content, could you make one video about tensorflow with go?

Gerald-izmv
Автор

A cool thing to add in a response is a field called responseCode or just code, as an int32.

Example:
message Response {
int32 code = 1;
...
}

In the server, you can use the grpc codes to return a status, like return int32(codes.Ok), nil or any code that is in the package.

In your client, you can check if the res.getCode() != int32(codes.Ok) || err != nil, to check if everything was computed as expected or not.

vitoroliveira
Автор

What is the magic project where you can also serve the REST API for free?

kjsteuer
Автор

Great content,
Want to ask you opinion about whether interface in golang should have prefix "I" or something,
I see many people, including me, not intuitively know if variable already a pointer or not

AltianoGerung
Автор

I'm new to gRPC coming from websockets using crossbar.io and Im trying to understand a couple things.

If gRPC multiplexes over a single tcp connection how do you create the server to actually accomplish that single connection when using micro services and a front end web client?

Every example I can find has each service acting as its own server, for example lets say we have an auth service and a todo service both completely separate and independent. Does this mean that in my web client I need to first connect to the auth service, close the connection then connect to the todo service? Do I connect to paths e.g. localhost:8888/auth localhost:888/todo Or do I need to implement some sort of gRPC router which the services and web clients connect to?

g.l.k
Автор

what do you not like about gRPC, and how do you deal with it?

Goodvvine
Автор

Hacerlo por HTTP significa que no se requiere crear el net.Listener? Esa sería la única ventaja?

Alexyslozada
Автор

Can you implement a microservice architecture with grpc!

soundharnatarajan
Автор

Would you say gRPC could replace REST ?

kamilmazurek