 Hello, everyone. I'm Jay. I'm working for new lab, new lab company. And I'm a backend engineer. And actually, I'm living in New York. I'm not living in Singapore. So I just came here for business trip and seeking some Opportunity to talk. So here I am. And a little bit introduction. I don't have slides for myself. So I just, yeah. So I joined New Lab three years ago. And New Lab actually, at that time, I joined as a Java developer. So at that time, New Lab, one of the New Lab products, Which is Kaku, I created those slides in Kaku. It's an online diagramming tool. So New Lab decided to change Kaku from monoliths Application to microservice. So we started to use Go. So after I joined New Lab, then I become Go developer. So until now I'm three years old for Go. Then, and that's why we would like to do some talk for Go Since we, like now we are doing Go in our daily life. And I also have my own meetup in New York City. So whenever you have time, if you come into New York, Let me know and perhaps we can set up a meetup. Then you can join or you can come to talk. So yeah, it's Bowling Go Land. Our New York office is located on the Bowling Street. So today I'm going to talk about Go being data. How many of you already using Bing data? So perhaps it's not these two, but the description is like You can build all of your other file into a binary. So if you're already doing Go, so you know when you do Go build, You build all of your Go file into a binary executable file. So how about other files that's required for this application? You will need to upload those files into your server and your Go application will need to access the file system. So in this way, then you need to manage the file system on your local, on dev, on staging, and also on production. So in this way it's really, there are more things to do, More things to manage for your deployment. So Bing data is actually doing, okay, this is now working. So usually the Go, when you do Go build is building into the binary But other files you will need to put into the same file system. So if you do Go Bing data, then that will need, That will include all the file into your Go source code. So when you build your Go file, then everything will be built into one binary data. For Go Bing data, the really good use case is for web service. So here is just a pretty basic introduction for the web service. Web service is usually including two parts. First is backend. Backend when you run backend is running up the Go server and also create all of the endpoints and also serve the assets file. Assets file means the front end. The front end is to display and interact with end user. So your front end actually is just file. Your file is served into the front end. So the method is a phone or a browser. So your browser will open up the file and execute of the code in there and start to load all of the assets. For example, in this diagram, on the left side is end user. The end user loads the root path, which is slash to our server. Our server creating an endpoint with Go language. So first it's hitting into Go endpoint. Then, since this is a root slash path, so perhaps it's loading index.html or like home.html. So the Go backend will need to access file system. The second layer is the server file system to retrieve the file. Then, serve back to the client, like render the HTML. Then your client will execute the HTML and start to find all of the required assets. Usually it's like JS, CSS, and image. This is not like one request to the backend for all of the assets. All of the assets is synchronized, requested to the backend. And the backend is doing the same thing again as the server file system retrieve file loading into the cache and serve back to the front end. So this is then the usual web service. Then how web service manage the files. So creating a web server in Go is pretty easy. You're just writing Go, like creating an endpoint, and serve some endpoint, open up some endpoint. Then the second one, the second, the Go will start to listen to the report, and whenever they have any incoming request, the Go will start to access the file system and retrieve the HTML, CSS, and image files, and then serve back to the front end. So this is how a regular server will host. On the roots, usually we have a built file, which is Go binary file. Then on the same root, on the same path, you have the slash assets folder. Under the folder, you have all the files, like JS, image, and CSS. Then everything will be hosting on the Go server. So you don't need to worry about anything. You just upload your Go binary file and also all of the assets into the same path. Then the second one, for Engine X to serve assets file, is usually for marketing website or landing page. Your Go file doesn't need to manage the assets. Your Go back end will just need to perhaps for HTML to serve HTML, since when you build HTML in Go, usually it's a template. So Go will need to grab over the file and pass into the regular HTML, and serve back to the front end. So when the HTML rendered back to the client, and when the client needs all of the assets, actually this will go to the Engine X path. So Go doesn't need to manage any assets file. This way it will be more clear, but however you still need to manage all of the file system on your server. After you're using Go BIM data, then you only need to have one file. After you build it, it's only one file. Then you take this file, upload it into your server or your dev environment, then you just execute this file. So the difference between this side and the previous side is actually just the second one, load all of assets after creating all of the endpoints, which means after Go server runs up, everything will be loaded into the cache as a memory. So your Go code doesn't need to access the file system anymore. So you can tag this build file into, you can upload it to a server or build it into a container, like a dark container. So everything what you need to do is just execute this file. Then you have everything. So in this approach, what's the pros and cons? The good thing is we serve assets faster, since everything when you run your Go file, everything will load into memory. So your Go doesn't need to have time to load the file from the file system. And also it's not near to know where it's located, since it's all loading into the memory and it's already finding the binary into your Go application. And it's simple deployment, since you only have one file. You don't need to manage anything. But however, you still need to manage the file system in your local. Since before build, you still have those files. After build, those files will generate into binary and merge with the Go executable file. And also it's suitable for container. Usually the container will be as simple as possible. So we are doing this way in all of our microservice. It doesn't matter if it's front-end or back-end. Sometimes back-end, sometimes like some microservice only for back-end, also need some files like configuration file, like JSON file. So we are doing this way. Then we don't need to worry about where is our file. Then the fourth one is we don't need to manage files on the server anymore. But however, on the local, you still need to know where's the file, when it's built into the binary. So CUNS is like the first one, two more libraries to install. So if you don't need this system, you don't need to install the two more libraries. The first library is building your file into binary. The second library is for creating some kind of file system in your Go code. So in your Go code, you don't need to think about where is the file, but you still can use like slash, SS slash, like JSON file. You don't need to just include binary into your code. The binary is still separate into separate code base. You don't need to know that code base. You just need to access the file system like on the server. So later I will demo my machine, then you will know like how I manage all of the file system in the Go code. And also Go doesn't provide an easy way to build the file into binary. So that's why we need these two libraries to help us make our code easier. And also you must deploy the whole application even for front-end code change. So this problem is more like monolith application issue, right? So if you are hosting a monolith Java application, if you're changing just fixing one typo, you still need to redeploy the whole application. However, Go, this language is not suitable for monolith application. So usually if you are really good at like how to divide your functionality, then this shouldn't be an issue when you deploy your front-end code for just changing the small thing on the front-end. This should still fast to deploy it to the production. However, this is still down a point because if you are not using the binary, you can just upload a JS file into your server file system. You don't need to restart your file. Okay, cool. So the third one is it will use more RAM. It's obviously because you're loading everything of your assets file into your cache. But however, this Go Bing data is using compressed technology. So for example, our website, our Kaku landing page website, we have a lot of page when we build everything into one binary file, it's around 100 megabyte. So it's big. It's much bigger than regular way because Go, after you're building into a binary file, then it's usually like 10 megabyte. So it's like 10 times. But however, we found if we do this way, the speed is 10% faster. Since it's not a new file system anymore and for developers, it's much easier as well when we deploy to production or dev environment. So how we build all the assets to the binary and empty into our code source code. The first install Go Bing data library. I have the path in the end if you want to try. The second one is Go Bing data assets. FS means file system. Like reduce some kind of file system that you can use, but you don't really need to access the file system. And third one is just using Bing data actually and command COI tool. So you just run Bing Go Bing data and always output and ignore and also debug. Debug is really important for local environment. If you set the debug to one, then it's not building your assets file into binary at this time. It's just adding the path into your binary data. So you still access the file system. So whenever you're changing any HTML, your assets file doesn't need to rebuild. It's still accessing into your local file system. Then others is just prefix and where is your local assets file path. Then the fourth one is like tool. Go generate. Like does you all know Go generate? Yeah. Go generate is really a suitable tool for this case. So because every time when we build the Go file, we need to do Go Bing data every time when you build. So if you write this Go generate in your man that go on the top, then after Go generate, you're adding the Go Bing data command. Every time when you build, you also need to do Go generate. Everything should be fine. So there's no extra step for you. Then the finally, you just need to edit your code to access to the file system that's created by Go Bing data assets FS. So here comes to demo. So I'm going to demo a really simple website. It's like a marketing site landing page to introduce our product. Then I'm going to talk about how my local file system works and how the building Bing data system works. Then I'm going to orbit and upload into a server. Perhaps if I have time, I can add into this darker container. But usually like in a darker container, we just added the file into that container. So it's the same thing as you upload your file, the only file into a server. Then deploy it to a server. Today I'm using darker digital ocean. So yeah, digital ocean is pretty easy to use. So I just created a digital ocean there, uploaded my file into digital ocean. Everything should be good to go. So yeah, I'm going to do the demo. This is my local code. So those things you're going to know, I'm using IntelliJ, the IDEA build and node module. Actually I add everything, like the configuration file on the loose path. First is darker file and the go mode, the execute, the entry point of go, and also even the web package that just on the loose file. In this way, actually we found that this way is pretty, it looks messy, but when we get used to with this system, it's actually quite easy because everything you need is on loose. So on this file system, on the assets, I add everything into view folder. So in the web pack, after I execute the web pack, then everything will be built into the assets folder. The assets folder is at the build. Then everything I need to do is adding all of the files under the view folder. So let me show you the website first. So I'm doing young dev to bring up two servers. One is web pack, another one is go. So in here I'm actually using a web pack library called concurrently. This tool is able to bring up multiple servers or you can execute multiple commands at the same time. So in here I'm executing web pack and go at the same time. So you can see there will go and also web pack. Web pack is just building all of the assets file into the assets folder. Then this is the website that I built. This pretty simple website is just the first page and the inner page. So how I manage of the image and also the page. So under my template folder, it's actually using go template. So under like head, you can see I have a version that's from go and the home also including head and the command .html that's using go template. So how we building this bin data? So in the Mac file, I actually have this go bin data command that's building everything into this folder and this all is output into the bin data.go. You can change this name to anything. But the folder, you can define which folder you are going to build to. So under this file, this bin data file on the top, you can see this has list out of the assets file that's already include into this bin data. However, because I'm using debug mode, so you can see the path is actually my local path. So if I remove this debug to zero or just remove it. Then I execute again. The bin data will include the binary into the file. So your local shouldn't have, you don't need to see this until you are ready to build into your production. So this file including all of the assets into binary in this file. So also the file system is works in this bin data because you can just access the file system like a regular local file system. You don't need to change the way to retrieve file. So in my go, main.go is pretty easy. It's just creating a port and using a router.go. And in this demo, I'm using GIN. Anyone using GIN framework for your web application? Nice, they have one. So I'm using GIN because it will be much simpler in the code. If I'm using go native language, then I will add a lot of code in here. So in GIN, it's pretty simple. You create the go, the default route. Then here I set template of the file. Where is the file path? Then surf this as the file system. So static actually slash assets will be loading for all of the assets file. Then the first homepage will just need to do this file name. After you have the file name, you can just load from the file system. The file system is actually just from your code code. It doesn't need your local file system anymore. So in here, this is like extra work for us to set a template. Since not every file is just static file. For HTML, we need to build this with a go, since this is a go template. So we need to add over the file into the system. Then when it's retrieved the file, then that will build out with a go template. So in here, you can see when I do young build, it's actually build from end first to the folder and also build the go into one binary file. This is also open up the, so I can just do make. So first, we do go generate and then building up the go binary file with Linux. Then I already prepared a server that's from Digital Ocean. Then I can just upload this file into my server. Okay, hopefully it's fast. Oh, okay, yeah, it's fast. Then we do SSH into the server, then find the file. So the file is binary. You can see the binary is huge since this including all of the image and all of the JavaScript and CSS. So execute the binary, then the server is up. Then we can just go to the server with the port. Then everything is serving in this server. You don't need to upload any other file, only this binary file. Okay, that is the demo. Then this is just helpful resource that if I will share this presentation, then you can just get in my demo code and try the bin data because this is really useful for us. I would like you to try this as well. Then new lab, but now it's actually hiring. So if you are looking for any other opportunity, you can take a look on our website. Thank you very much. That's all my talk. If you have any questions, yes. Thank you. Thank you. Actually, we have the same problem. So in this, we don't have solution. So that's why we only use gobin data for the static file. Hopefully, if I find any new solution, I will share. Thank you. Any other questions? Thank you very much.