Видео

Incomplete - He needs to slow down and give more details. What about float double etc.

3:05 is ridicules now that I learn SQL, it's nuts in fact. Thing is I never really cared about it before when I knew only how to use ORM.

this is perfect! im creating an ai mircoservice for my app and this technology would be perfect as the ai mircoservice is called upon by my main api to get the closest coordinates based on a list.

Although this maybe useful in some projects please also research the tradeoffs that Protobuf introducing

Very interesting, thank you!

маладес

That assumes that management would allow it, but management believes that REST is the way to go. You don't buy Gucci bags because you need and handbag do you?

This would need very hot cows to (not) work.

So they were sending the radioactive cows eastwards so that they could mix them with the non radioactive ones so that the meat, on average, was not contaminated ? How's the steak Sergei ?

Go vegan

Protobuff dosent's "change" anything about serialization, real programmers used Binary formats since 90s. It's sad that web devs are so ignorant

name one thing prisma cant do i will switch to raw dog

how do i know this guy is german, when he said 99.9 nein nein nein NEIN NEIN

during CompSciGuy , 172 views , 16 hours - Raw

thats a wild story man

"That's a lot of boilerplate" *rewrites in Java* Okay bro

Probuf best practices: "Don't Add a Required Field", "Don’t Change the Type of a Field", "Rarely Use an Integer Field for an ID"

ill never take advice from people who use windows software willingly

if we just had a ProtobufMessage.safeParse(blob).as__AllRequiredFieldsPopulated(), without the parsing error, then everything would have been fine

too much code for this gRPC thingy, i'm stickig to REST all day.

Honestly having been forced to use ORMs at work, and also having to migrate between databases (for bad reasons, don't ask); when moving between databases, you WILL find inconsistencies in ORMs where they handle a migration set just fine in one db, but utterly fail on another engine

making rest api requests from DATABASE ? hard pass...

It seems that by the comments people are generally opposed to this. I personally like the idea of a "jack of all trades" database like postgresql because it keeps everything in one place. No need to orchestrate a bunch of different services. Ome good example is saving a record from the front end and not having to then call a separate message queue. The database takes care of it for you. It also ensures that no matter what or who saves something to the database the message always gets cued on the database side.

Such code throws error on my side TypeError: Cannot read properties of undefined > const message = proto.mypackage.

Super

Bunch of butt hurt ORM users in the comments.

There are more fundamental problems: int8, int16 are not there anymore so it will surely waste network resources. Also in C++ editors, finding the names for get is not easy. You better look in the .proto files, since the .h file from protobuf is a horrible file to find your way. For simple things, just create a socket to communicate in 5 minutes for complicated things with many messages then protobuf or mosquitto is the better option. for communicating to many devices, protobuf is wrong and you need mqtt wit mosquitto.

Thanks. I'm struggling to understand how to use the google protobuf. This was very helpful. There is a way to have an auto-generated code from the proto right?

Love the conclusion. I have spent so much time convincing people they don't need a distributed SQL and just a highly available setup or NoSQL (speed related). There are so many ways to resolve most client requirements other than distributed SQL.

Keep doing this video they are very good, thanks

Great video, thanks!

A backend in python will never be fast anyways 😂. Just teasing. Thank you for this grpc lesson

Thanks for this video. You raised very good points which has benefitted me immensely. Your video also led to a follow-up video by thePrimeGeon netflix guy. So thanks 😊

I do something similar with currency conversion. My application periodically queries conversion rates on all the currencies we support and caches the data, then we just calculate the exchange and inject the values into the SQL query. No need for adding functions to PG/My or anything fancy. A caveat for this method is wildly fluctuating currencies like Zimbabwe or Venezuela that may become outdated very quickly, but our use case only requires major currencies like USD, CAD, AUD, GBP, EUR, CNY, JPY, THB, and other European ones, so mileage may vary. Sometimes the simple option is the best, like now NASA spent millions developing a pen that can write in zero-G, whilst the Soviets used pencils.

wtf are you talking about. most of the arguments are silly.

Dont use grpc in your backend. Use graphql.

Nice! Flatbuffers have the same problem?

You need to know sql anyways .Orm is great tool , if u have complex queries you will debug thus anyways and put some optimisation , ORM does not matter here. SQL != ORM . SQL BUILDER != Object Relational Mapping . Author lacks understanding this. You can write sql and use ORM to populate items.

If that would be me, in case of currency on the backend I would rather pull conversion rates first (with possibility of caching it if this endpoint call frequently), then during request I would use CTE like: WITH "conversion_rates" ("currency_from", "currency_to", "rate") AS ( VALUES ('USD', 'EUR', 123), (...) ) and then use it in expression in other CTE/subquery

subliminal messaging worked. I subbed

Absolute bullshit. Everything you have stated here can easily be mitigated by a modern ORM and a developer whos IQ is above room temperature.

nothing in CS is straight A. It all comes with its own compromises You any day need APIs like rest/gql however you try. You have to send data yo some client

For most people who don't understand isolation levels, isolation levels are usually not what's slowing down their queries. It's usually because they don't know how to add the right indexes. As a sysadmin I've had two customers request that we lower the default isolation level from repeatable read to read comitted. Why? Because Stack Overflow told them that it would fix their deadlock errors 💀 (Repeatable is the default in MySQL, thankfully)

What is the classical piece in the background? Sounds like something from baroque.

We always knew about subqueries and functions/procedures in SQL, just that the time those take is way larger than just getting the data and processing it in our programming language of choice.

I get that it's an example but for most use cases it'd be better to keep a table with the daily currencies and you call that function to insert new rows when the current day isn't found, instead of calling an external API whenever the query runs. But hey, I had no idea you could integrate Python into SQL which was really neat to see.

Lol I thought you were about to say SQL as "squeal"

Just get the exchange rates every hour/min/sec and insert them in a table, which is joined in the main query. Making API calls from SQL is stupid.

The fact that subqueries and CTEs are not common sense sounds frightening, to say the least.

Think you can simplify the average trade query using "having" keyword. I personally try to avoid named subqueries in all but the most complex queries.