Link dead, seems like that service from acorn is dead. @dreamsofcode

@@ericowens3023 rip. Thanks for letting me know! I'll figure out another solution!

Protobuf is a burden, let's stop pretending it's not.

Why serialize in REST when you can use a proper tool? Laziness?

@@blender_wiki Because protobuf presents a sea of ​​problems below the surface, For example, the foolish decision not to allow null and to represent 0 as null, so I have no idea for example if a temperature sensor displays 0 degrees Celsius or simply returned null, Oh sorry, you can also have a has function and then check each time during runtime. What a beauty, so useful!

@@fullmetalu320 I've never said so, and that's also why I mentioned CBOR. I was referring to the general advantages of binary serialization formats.

@@fullmetalu320 Lol, this is absolutely bunk. Other serialization formats, like JSON and XML provide absolutely no type safety at all. The decision to NOT include NULL was deliberate! We DO NOT want the null problem, where arbitrary values can be valueless. We want the minimum amount of variants for our types, as this reduces complexity. Consider this: How many values can a JSON array named 'books' represent? A LOT, including null and "null" and 0 and {} and undefined. We have to, yes HAVE TO, handle all these possible variants in a robust application. We can make a schema, which helps a tiny tiny bit, but this still raises complexity because we have to change the schema along with our application code, or else it doesn't work. This introduces a new plethora of bugs that are not possible in protobuf.

every few years, some new binary serialization protocol comes out. it requires code generation and build steps. then go back to text based protocols again json (or xml etc). the Hadoop ecosystem kept making a bunch of these. corba, wsdl, soap, grpc, avro, .... what we really want is a contract-first definition of the wire protocol between services so that it can be stable and versioned, and integrated documentation. we want to hide all the mTLS madness in setting things up (through sidecars/meshes, or libraries, etc). web sockets, etc. it seems like the protocols that win are the ones that are the easiest ones to reverse-engineer from a running system. grpc forcing you to not use stock HTTP/1.1 is a big drawback. now a huge problem.... you need to start transporting files and media. now the grpc stuff thinks of the world as tiny little messages. but in the middle of this, you return a link to a 4GB mp4 file. and it doesn't fit in with the rest of the system. you want to use grpc easily from javascript, etc. there is an AWS service that can take GraphQL and automate doing persistence for you. grpc has aspects of what we really want to do, but build messes and hard to reverse-engineer existing systems make this hard. building things based on on-the-wire-message definitions is good. but it's an error if you try to send a message to a service that is down. what you want is to be able to enqueue a message locally to go out. the network may be going up and down, and you turn errors into mere latency if things just queue up and drain when the network is up. offline-first clients from the browser, etc. there's a lot of half-solutions that get wired together; and we still don't have declarative protocols that keep the docs up to date, and handle the security and robustness issues; while still transporting over whatever is available. (ie: http/1.1, tls, and websocket issues).

I'm sorry, but what is REST format? (JSON is not a part of the REST, HTTP is not the part of the REST)

@@mykyar9142in practice, you get forced to use tools like OpenAPI that all but assume http calls with json bodies. Your whole enterprise can force you to go through proxies; that can no longer handle non-http calls, or graphql, etc. in reality, REST assumes json bodies. i got so tired of fighting this when I was still using actual files (ie: mp4, jpg, etc), and going through proxies that just expected that all services are based on json. it's like multipart-mime, or large files are not a thing.

If you design your API property sincecthe beginning gRPC have zero drawbacks for a private/internal API.

also reminds me of GraphQL a lot, but perhaps less confusing

This might depend on what you're working on but I disagree. REST is good for CRUD services, but CRUD services generally aren't that great in the first place. If you write services based around business logic/domains, RPC often fits better. That said I see a lot of pseudo-rest RPC services in the wild, where it should really be RPC but it's been written as if it's REST. For example you might see a get signed document where you post an unsigned document to it, but that's really a sign document RPC API. It's clearly not a nice API, but that's because someone was trying to use REST where RPC fit better, and they ended up with neither. Just a toy example but if you look around it happens all over the place.

I will call you on that. Tell me one real world use case that uses a *truly* RESTful API. Many say they do, yet I have seen absolutely none. REST absolutely does not fit the real world at all. That does not mean everyone should jump to gRPC as there are other options, each with different benefits.

@@aleksandarsusnjar9574 If you are just straight retrieving data, then rest has an edge. You can use a get request which can be cached more easily in internet infrastructure like cloud flare. gRPC uses post requests. 90% of what happens on the internet is retrieving data as well. If you are trying to update data objects I’d call it a toss up and for everything else gRPC has an edge. As for whether something is really “REST”, the true REST was never a real thing, just academic nonsense. The real REST is exactly what the community and professional world understand it to be, not what’s in an old outdated book that one guy wrote and almost no one uses. That said HATEOAS is an underutilized part of that original REST design, that more people should think about. The point is that real developers took the parts of “academic REST” figured out what was useful, discarded what got in the way and “Real REST” was born. You can’t truely define a real world API design until the real world actually uses it. Final note: You can make a strong argument that graphQL makes for a better data retrieval API in a lot of cases over REST, but it also doesn’t use get requests. So in the case that you are maximizing scalability for retrieval of fairly static data REST is quite peerless simply by virtue that it uses get requests and internet infrastructure can cache those better.

​@@aleksandarsusnjar9574yeah, my wife used to work on a project as mobile dev. Backend API was restful written by old beard folks, they probably read a lot of interesting books... So on clients side mobile/site has to call like minimum 3 endpoints to collect necessary data for one entity, and sometimes even more sequential calls were needed as next response lead them to another urls. Needless to say the app was super slow and everyone blamed the frontend as by metrics backend responded pretty well

What are your guys opinion on GraphQL?

Thank you!

Haha I really enjoyed that one 😂

Thank you!

Thank you for sharing the knowledge! I'm going to check out boats as you're correct, writing it in smaller chunks would be nicer. I like to take a contract first approach for the reasons you mentioned, so will be happy to have tooling to improve it!

@@dreamsofcode happy to help :) We use it for all our projects and it works really well for us. Takes a little getting used to but once you're familiar and have some nice helpers it's super fast to add or change any endpoints or schemas. Always up for finding out about new tools as well in case you come across any alternatives.

Thank you!

The browser does not support it tho

We use it at work. There should be lots of tutorials online

That's really interesting! I'm going to see if I can find the article. Thank you for sharing

Hey! Thank you. I'm still planning on showing how I do them. I use Davinci Resolve for about 90% of my editing and then use After Effects for the rest. I'm likely going try moving to Premiere one day also!

I shall add it to the backlog!

I'm not sure if OpenAPI generates from code, but I know they can do Codegen to generate clients from the contract. I'll do some more research on it! You're correct, it can also be used for real time communication. Another viewer mentioned that Valorant uses it for game clients! Thank you! I'm glad you enjoyed it! Thanks for the comment as well, interesting discussion 😁

@@dreamsofcode Node Fastify is able to Generate well-documented opeaAPI 3. Spec from your JavaScript/TypeScript schema in your code. And with openapi-typescript you can generate TypeScript types from the open API 3 spec on the server for your client

Thank you!

I agree. I tried around and found my way to Prost, but what's available in the ecosystem is usually lacking in features (reflection, for example) and is hard to actually configure. I do think that gRPC support is coming for Rust, though, as protoc has experimental support for Rust, although I haven't really tried it out. I also looked through the protobuf repo and progress is still being made for Rust support. Even so, Tonic does seem fairly mature. Still, an official package would be nice.

Thank you! I'm in the process of revamping my Neovim config and will be doing a video on it soon 😁

Acorn Labs I believe is their full name! They're the same founders as Rancher, I believe. Really cool company!

Great question! As long as you don't change any field numbers or types then you should be fine. gRPC will handle anything missing. Basically, don't do breaking changes!

Out of the box. No. But! There are plugins that can add validation rules with protobuf, protoc-gen-validate I believe is one of them

I absolutely can and will! There's some cool gRPC tooling in Rust

REST apis are sets of urls and json, something browsers can do out of the box Protobuf support needs to be implemented in javascript/wasm so it's not supported by the browser out of the box, meaning it's probably slower to decode

It’s one of the last things he says at the end of the video

Agreed. The gRPC team are focusing on gRPC web next year however, so there might be some improvements coming!

grpc protobuf does support grpc json-transcoding. Meaning writing one protobuf file, then once u process it with a protobuf compiler, it will generate two kinds of API schema: Http Restful API endpoints + Grpc API endpoints

@@dreamsofcode Buf Connect is great for the web, check it out!

You can send up authorization headers the same as you do in REST. So from there it's however you're performing rbac i.e. using a JWT or session based auth.

We've come full circle 🤣

Yeah I think if you're not keen on gRPC then don't use it! For me it takes away a lot of boilerplate so I'm happy with it. As for better error handling, there's the richer error model which does allow for improved error messages, Ill probably do a video on it in the future but check it out if you're interested!

/add isn't restful design. It violates what a restful app would look like which is to perform CRUD on resources. Add is an action, not a resource. You could still do it of course, you can technically do anything, but you'll end up with a poor DevEX and future devs will dislike the decision. The other benefits of grpc are: Contracts, performance, streaming, bidirectional communication, and more.

Actually, the use case of this video is a bit of a red herring. Nobody would send tiny action calls through the Intertubes for a calculator. Actions in most applications and use-cases happen on the client. The only use cases where finely granular actions need to be communicated through the internet are e.g. multiplayer games, chat clients or real-time Multi-User editing in documents (think Office365 or Canvas boards).

I use Alacritty!

Some languages still have to! It's also common place to write an API spec before building, in order to agree to a contract with multiple teams.