 Okey. So, my name is Sunny. It's in my notes. I work at Brassfalker's leisure. It's a high frequency trading firm. So, I think investment is a smaller scale. So, I'm a software engineer with them. Currently, I'm building JavaScript-powered platforms for traders to make quick trades. So, before I move forward, so today I'll be talking to you about protocol buffers. It's a way of serializing data when you want to send across the wire. But before I get that, I think I like this concept of meta-learning where in the subject that you're going to learn, there are some other nuances that you can pick up. And one of that is in today's meta-learning would be there's no best. When I talk to you about protocol buffers, most of you might think, oh, this might be the best thing or this might not be the best thing. JSON might be the best thing. That's not the case because you always have to approach it in a very objective manner. So, when you want to decide whether you want to use this, you find out what your requirements are and then match it against benchmark what your current status is. Match it against what's happening and then decide whether you want to move forward with it. In this case, you're talking about protocol buffers. You're talking about transmission of data over network or storage. So, you would be, oh, what's my file size or how fast does this transmit? Those questions need to be answered first. So, moving forward, okay. So, it's a way, protocol buffers it's by Google. It's a way of serializing data for storage or for transmission over a network. The way it does this is that it converts into binary format and then it streams across whatever platforms you have. One of the very common other ways is JSON and XML. I'm sure most of you know about it. Right? How many of you know about protocol buffers? Fantastic. Nice. Okay. So, we've been using this quite extensively in my firm. So, like I said, it's by the guys at Google. They've been working on it quite extensively as well. It's an open source project. The next few things is it's platform enostic, meaning I could have a Node.js server or a Go server talking to an Android device or a Swift, an iOS device. So, you can transmit data in a very fixed format over the network. And diserialisation and serialisation, everybody knows what that is, right? Anybody does not? Okay. Happens through various APRs that they have available in multiple different languages. So, you can talk about Python, JavaScript, C++, Ruby, right? So, now that you know what protocol buffers are, let's try and take a look at what it is, what it looks like. Okay. So, to get started, right, you would need to have three things. One is generated, two are required. So, first you have your protocol file. Think of it as your schema, right? If you look at it carefully, it's quite easy to understand, right? Syntax just means that I'm using protocol version 3, and then here I'm describing an enum to say that there are three types of phone numbers, right? And then everything is a message, as you can see, right? And, for example, the phone number I would like to say that the number is a string and I'll tag it to one. Now, this is why protobus are very, very powerful because they do not collect metadata like JSON does, right? They identify via this number here, right? So, converting into bytes would be a lot more faster. You can compress data, make it more dense as you transmit over the wire, yeah? You can also have collections in the same struct where you say it's a repeated field so I can have multiple phone numbers called phone and I'll tag it to four. I will not go into depth about the technicalities. You can easily read them up. For me, it's just tell you more about what this is, yeah? Okay. So next, once you have your protofile, you'd have a compiler, right? It's called the Protox C. What we do with that is to say here's my protofile. I need it to be compatible on my C++ platform, right? So it compiles in outputs and API that you can use to access to deserialize and serialize data that you want to transmit over the network, yeah? So other generated APIs include like C++, C sharp, Ruby, Python. The one I have here is our JavaScript output format. So as you can see for phone number, you can set the number or you can get it, right? The API is a lot more extensive than this. It's a lot more powerful. I'm just giving you a small snippet of it. Yeah? Okay. So what happens is that usually you would have one copy of this. You'd compile out two versions and then put it on each server or client that you have, right? And now I'll explain more about some of the nuances that you might want to observe. Okay. So because of the other API formats, you don't need to worry about whether your platform is on one language or one platform. All of that does not matter. Next. This is a bit complex, so I will try and take it slow. Okay. So the workflow is this. Let's say you have a Go service and you want to transmit stuff to a client further down the line, right? One of the things is that your Go service will call an API, the Go API, which will then serialize it into whatever format. Points for whoever can figure out what that is. And then it transmits over the wire. Okay. Hits whatever Node.js server or any other microservice that you might have. And this is where protobufs are most powerful, right? This packing that they do here is very dense in the sense that it's small file transmitted quickly over the network. So a microservices architecture would best benefit and I'll tell you more about when it does not benefit. Okay. So Node.js server gets it, calls the API, this serializes into JavaScript objects. That's what it needs to do. Serializes it into JSON and then transmits to the client. So some of you might be thinking, you know, this is very inefficient. You're like converting from one format to another. Like I said, only when you have microservices architectures then this would matter to you. Now now that you know what the flow is like, I'm going to quickly move on to my most important things. Do not use it if. Okay. One, your data is directly consumed by the browser. JavaScript is fantastic. Our browsers are very powerful, right? So do not use it if you're talking to a browser because browsers use JSON very well. They're optimized, right? So stick with JSON. Yeah. Okay. So what's the best thing you can do native binding is very powerful in JavaScript and your browsers. Next, your large packet sizes. So ProtoBuff excels in a very specific file size. If you hit above 1MB then you need to re-think your architecture, right? If you're transmitting more than 1MB of data per packet. And if it's below 300 kB JSON vs ProBuff, ia sepatutnya sama. Pekan itu adalah sesuatu yang perlu anda fikirkan. Mereka akan menunjukkan bahawa jSON lebih kencang atau ProBuff lebih kencang. Itu adalah scenario DR, bukan kamu. Jadi ingat, perkara yang saya ingin anda lakukan daripada ini, adalah menikmati konteks kamu dulu dan lakukan test kamu. Jadi, bagian besar-bagian besar. Ini sangat penting. Pada peluang yang mudah, beberapa orang mungkin mempunyai projek yang anda bekerja pada perniagaan. Jangan gunakan ProBuff. Jangan harapkan masa untuk mencari. Kerana JSON akan menjadikan kerja dengan cepat. Kamu mahu faham data struktur kamu. Kamu mahu faham bagaimana anda gunakan. Bagaimana cara yang lebih kelihatan untuk mempercayai perkara itu? Kemudian, apabila anda melihat peluang, anda akan melakukan perkara itu. Jadi, melepaskan meja-lelearnanya ini adalah optimisasi yang lebih kelihatan. Jadi ingat. Okey, apakah saya harus gunakan? Okey, ya. Jika anda mempunyai perniagaan JS yang bercakap dengan Android native atau Switch apps, kerana anda tidak lagi menggunakan perniagaan. Jadi, perniagaan JSON mungkin tidak menjadi optimisasi seperti yang anda suka. Tapi ProBuff adalah optimisasi yang lebih kelihatan. Jadi, ia mungkin adalah idea yang baik, jika anda mempunyai perniagaan JS yang bercakap dengan aplikasi di luar perniagaan. Ya, perniagaan micro-service mempunyai beberapa perniagaan. Jadi, itu adalah kesan di firm saya. Kami mempunyai beberapa perniagaan, semua bercakap dengan satu sama lain, perniagaan kita adalah pada perniagaan. Jadi, di antara perniagaan, perniagaan komunikasi adalah ProBuff. Ya. Jadi, perkara seperti ProBuff, perniagaan ProBuff adalah lebih baik pada platform java, seperti yang berkumpul dengan perniagaan JSON. Jadi, jika anda mempunyai perniagaan java, anda mungkin mahu melihat itu. Dan... ini juga membantu kami kerana mempunyai perniagaan perniagaan java memperkenalkan banyak bahan-bahaya, dan seseorang mempunyai perniagaan java menjadi sesuatu yang lain dan mengambil perniagaan di luar perniagaan. Ya. Jadi, anda mungkin mahu membantu anda di dalam perniagaan. Dan perniagaan data yang tinggi. Jadi, ini adalah perniagaan yang menarik, kerana ingat bagaimana sebelumnya saya berkata, jika anda mempunyai perniagaan java, jika anda tidak mempunyai perniagaan java, ini adalah pilihan yang hanya anda mungkin mempunyai. Jika anda mempunyai perniagaan java, kerana berkata-kata dengan XML dan JSON FALSE, XML seringnya, ProtoBus adalah sekitar 3-10 kali lebih kecil dan sekitar 20-100 kali lebih cepat dalam transmisi. Jadi, anda mungkin membuat senjata, jika anda mempunyai perniagaan java, anda membuat banyak panggilan, atau anda mempergunakan pakaian web, anda akan mahu melihatnya. Ya, tapi anda harus mencari dulu jika anda mempunyai. Kita cuba menggunakan ProtoBus ZZit dan jason ZZit berbeza sekitar 30 kb, tidak penting, jika anda mempunyai jika anda mempunyai jauh besar. Jadi, ia adalah tentangnya. Jadi, ia adalah pilihan saya. Jadi, saya harap ia membantu anda mempunyai sedikit lagi. Jika ada satu perkara yang saya ingin anda semua mengambil daripada itu, adalah untuk mempunyai semua pilihan saya. Ia adalah, tidak terbaik, saya akan mempunyai dan membuat pakaian konteksial dulu, sebelum anda bergerak. Ada pertanyaan? Ya. Baiklah. Untuk kami, kami bercakap tentang 100,000 pakaian dan informasi yang berlainan. Apabila saya katakan pakaian yang tinggi, saya bercakap tentang banyak pakaian yang berlainan. Jika anda mempunyai pakaian yang tinggi dan besar, mungkin ada sesuatu yang salah dengan pakaian konteksial. Jadi, anda perlu memikirkan pakaian yang lebih kecil, kemudian anda mungkin mahu menggunakan pakaian. Tapi, jika anda tiada pilihan, tidak menggunakan pakaian. Kerana ia tidak terlalu optimal seperti yang anda mahu. Ada sebuah pertanyaan? Ya. Baiklah. Anda mempunyai pakaian konteksial untuk membuat pakaian konteksial. Baiklah. Jadi, salah satu perkara yang menarik saya tidak bercakap adalah pakaian konteksial dan protobuf. Biar saya kembali ke pakaian. Jadi, pakaian yang berlainan. Satu perkara adalah ada kompetibiliti kembali di sini. Jadi, saya boleh katakan saya mempunyai pakaian yang baru atau mempunyai pakaian yang baru untuk menerima pakaian. Saya dapat membuat pakaian baru dan membuat pakaian yang baru. Jadi, pakaian yang memerlukan pakaian normal, mereka dapat menggabungkan pakaian ini. Pakaian yang tidak memerlukan, mereka dapat menggabungkan pakaian dan menggabungkan pakaian yang lain. Itu satu perkara. Jadi, itu pakaian kontrol. Ia mempunyai kembali kembali di sana. Jika anda bercakap tentang pakaian yang berlainan untuk kami, bagi kami, kami mempunyai pakaian yang baru dan selalu apabila ada pakaian, kami akan menghubungi untuk membuat pakaian di sana. Ia tidak perlu menggabungkan pakaian. Ia boleh menggabungkan di luar pakaian. Ini adalah apa yang perlu diberikan di luar pakaian untuk anda berjalan. Jadi ini adalah perubahan yang membuat pakaian. Pakaian yang membuat pakaian untuk anda memakai pakaian untuk memasak dan memasak. Betul. Jadi, jika anda mempunyai pakaian yang sama, anda pasti akan mempunyai pakaian yang sama, seperti jason, apabila anda memasak, anda akan mencari jika pakaian semua sama. Ia adalah sesuatu yang tidak dikenali. Ia mencari jika anda memasak. Jadi, ya, anda akan perlukan pakaian yang sama pada kedua-dua pakaian. Sebenarnya ia adalah satu, kerana hanya satu pakaian perubahan. Jadi hanya satu pakaian pakaian yang anda mengubah tetapi anda menghubungi pada pakaian yang berlainan yang mungkin mempunyai pakaian yang berlainan. Ya, saya harap anda menjawab soalan anda. Betul. Jika anda mempunyai pakaian yang berlainan, betul. Sebab itulah, saya akan menyebabkan orang-orang yang tidak mempunyai pakaian yang berlainan untuk menggunakan pakaian. Jangan mencari pakaian ini, kerana ia lebih susah untuk menjaga. Tapi semasa anda bergerak, ini mungkin lebih berlainan pada pakaian yang anda mempunyai. Ya. Ada apa-apa lagi? Jika anda ada masa untuk bertanya, jika sesiapa anda mahu bertanya, anda akan bergerak? Okey, saya dapat mendengar dari mereka. Saya ada pertanyaan. Apa masalah yang terbesar anda mempunyai? Masalah serialisation. Baiklah. Saya menggunakan perasaan untuk menggunakan pakaian. Dan saya menggunakan pakaian yang berlainan untuk menggunakan serialisation. Saya perlu menggunakan pakaian yang berlainan. Baiklah. Jadi seperti yang saya katakan, jangan menggunakan pakaian ini sebagai transmisi untuk menggunakan pakaian anda. Jangan menggunakan pakaian anda. Dan kemudian pakaian yang berlainan untuk memperkenalkan pakaian anda. Dan kemudian memperkenalkan pakaian anda sebagai jasun, kerana javascript sangat baik. Memang menggunakan pakaian ini. Jasun objek sangat baik. Ya. Ada sesiapa yang lain? Ada masalah yang mereka mahu berbual dengan protobuf. Okey. Terima kasih. Terima kasih.