 Yeah, so let's welcome Vinicius Pacheco, and he'll talk to us about API and APIs on microservices with Go. It's my golfer. Because of him, I'm starting to call the Go lang. What I will talk, this talks about APIs and microservices, it's not a talk only about Go lang, it's about engineer. First of all, I am Vinicius Pacheco. If you want to talk with me by Twitter, it's the best option. And I'm a software engineer at glob.com. I'm a teacher at Caelum, a good school in Brazil. I'm a Brazilian guy. And I'm a Django Girls Organizer and theologist because we need faith to compile code. And someone know what is glob.com? Yeah, it's great. So glob.com is a great group, global, a great group in Brazil. In Brazil, we have television, cable television, newspaper, I think 50 channels, cable channels from glob.com, and we have a portal, glob.com. Glob.com is the arm of a group global and internet. And what is our agenda? It's a real case. It's not a fake app. It's a real case what happened with me at glob.com. So where I can use, where can I use Golang? It's a real case, you will see. And an advice. My English is really, really, really bad. If you don't understand, you up your hand and the, I don't understand, can you repeat please? I will repeat. And you don't understand again, I don't understand again, can you repeat please? I will repeat in Spanish because it's great for me. And oh, I can't understand, please. I will repeat in Portuguese. And if not so good, I will take help for my Brazilian friends. They speak English very well. So our agenda, at first the metrics, after that the problems, the road, and the solution. The metrics from glob.com, we have more than 50 million access per day. Unique access, it's not a repeat access, it's not all two people access glob.com twice. No. Unique access, 50 million. And a quiz, a simple quiz, like what's the best player in the world, player soccer in the world. And one quiz like this, 404,000 requests per second. And we have APIs like Gamify Soccer, Gamify Soccer plays, and other APIs generate 300,000 requests per second. If in the top moment, 900 requests, 900,000 requests per second. And now we're a VIP. All glob.com is by, is from world to big data, and the recommendation. News and shows, TV shows, and so forth, by the internet. And get user from, user log it, it's easier. Okay. And where am I, and these numbers. My team at glob.com is glob.yg. Glob.yg is the API to register the new users at glob.com, and the server orders 72 teams at glob.com, and the order five companies from Grupo Global. So if you do a new register, a new registration at glob.com, you use my API. And it's the topics of this. And our system is it, is a tower. We have at first a front end that is written with a scalar and play framework. And they send the request for two monolith APIs, big monolith APIs, with 14 years old monolith APIs written in Java. The monolith API on your right side, my left side, is written with a spring tree because he was refactoring year by year, but it's not so good. The other is pure Java with servlets and AJB in version 2.2, I think. And our database is Oracle. Yes. He's scary. I know. It's terrible. It's a freak. What are monolithic? Who thinks this? With a big block of code with all things and organized by the OOP and it's a lie. The truth is it. It's the truth. When you look a monolithic, a monolithic, it's terrible. And think with me, 14 years of the same monolithic, good developers, push code for this, bad developers commit code, and it's TIGERYs commit code, it's terrible, it's difficult. So this stack, this big stack, two monolithic monsters do only 200 registrations per second. And our two big monoliths that we need to maintain and solve difficult to change a little library and the risk of deploy is huge and merge are numerous and dangerous. It's not a good place to work. Let's move to new architecture. And I like a lot the sentence of Michael Fusco. When you think of microservice, you think, oh, it's a literal application. No. It's wrong. Microservice is not a literal application. It's a big application, a big stack. It's not a, you can't think these things, terrible. And microservices is not because the size of the application. The important is what he do. What the microservice do is important because this is micro, it's micro not because the size of the application. It's micro because you need to think, oh, run responsibility on this. And my team starts to do a job to create a new stack. And the main developers there are Java developers. And the other developers are Python developers. And other developers are, I don't know, metaphor developers, maybe. And we create the first, the first stack to test was called Kratos. Because the game, because the Kratos killed the gods. And the two big monoliths are gods. So we need to do this thing. So we started to write the code with undertow. You know what is undertow? Anyone know? Okay. Jboss has a server, a server container, it's white fly. The engine of the white fly is undertow. It's the more fast handler for Java. And faster than undertow is netty. But net you need to know the size of the request. All requests you need to know the size. And undertow you don't need to know the size of the request. So undertow is friendly for developers. Friendly for developers. Look at calls, friendly for developers. We started to write with undertow. And it was a Sunday. I don't have beta. And my wife slept with Jins, had slept with Jins. And I started to write the same application in Go. Because I like Go. Why not other languages? Because I like Go. I have a Go format. So I started to write. And we have a team. The name of the team is key A2. The key A2 is a team for tests of the stressor tests. And undertow pass for the test. And they put the other application. And I call it by golem. And why golem? Because data is precious. Data is my precious. So I start to write the code to golem. And put in secret to the key A2 team. Key A2 team made the tests. And was more performatly than the Java application. So my team looked at the numbers. And oh, Kratos is so fast. Oh, what do you do? And I think it's not Kratos. It's golem. And golem, there are a lot of motivation for his name. Because our golfer, when made a library, put the goal like a prefix of the name. You know batman? The bat mobile, the bat phone, the bat, you know what I'm saying? And the golfer put the goal. Golem, okay, golem. It's good. And what goal gives for us? Simply see. It's simply, it's more simple than Java. And the center library is really complete. I don't need a server. It's not necessary, JSON translator, it's not necessary, RPC to communication, it's not necessary, nothing. The all is inside the center library of go. It's compiled, so it's near of the machine as my language to high performance. The concurrence with goal is for babies. It's really easy to write a concurrence called with golem. And we have a lot of tools, many tools, fantastic tools. And there are native API for HTTP2. It's great for us. And a great decantation. So the simplicity, look at this, under tall hello world, great goal, let a class and a method main to run because it's a engine of the server, so you don't need to put inside the container it's provided. And you start at the builder of the under tall. After that put the listener, local host, and after that you set your new handler. And write your handler with a lot of boilerplate. And put what type you will return it in your handler, set the explain. And after that you write your hello world, build and start, easy, so cute, look I'm ironic. The same with goal, I put the package, the principal package, all code started from the main package, the main package is the principal, the main of the application, all code of the main package, and the main function. It's a reserved function of the goal line. And we start the handler and put the response and the request and I will print hello world. Put the handler, registration might hold, and after that listen and serve and 8.8 port. It's easy. Look, it's easy. It's not so difficult. What? Okay. This case will return a text plane because he's identified the text, hello world. But not a good practice. The good practice to do this faster is just set on the header, the return. But I will use, I've been used the fprintlm, so the fprintlm return a text plane. Okay. If I want to write a low level, I don't use FMT package. Okay. It's a friendly interface for developers. If you want to write goal code, you can't use FMT and the other packets roast for performance. So tests with goal. Oh, I need to import a package for tests, to do unit tests, no, it's not necessary. Go give this for us. And I put the log to know what happened. I import the net HP and look at this, fantastic HP test. Look, to mark your request. That's great. And the test package. I create a func to test the handler, oh, test handler. And import the test restriction, extract. After that, I create my new request, real request, okay, my real request. If an error happened, I will lock the error. And after that, I create my fake response. Create my fake response and the set for my handler. Take the code. It starts different of okay, return the error. With the okay, let's hello world. It's easy to test a handler. Nice. How can I do to give a JSON for my user? Is it? I have a function in Portuguese, sorry, and send a JSON in English. And I will return two things, a nice slice of bytes and an error. Because goal and goal don't have exceptions. It's this elegant. Yeah. What pike said this? And this guy is terrible. Oh, no. Oh, no, exceptions good. So we don't have exceptions. And why? Because you, it's easier to create your errors. An error is an error. That doesn't port what type of error it is. And the, sorry, we put, I have my package user, my entity. I create my entity. It doesn't matter. It's my user. And I create a new payload. And this payload, it's a map, a string and interface. Interface is, doesn't matter the object. It's like the father of the object. It's interface. But look, it's not only interface. It's interface with how the name of the sign. I don't know, in English, please. Braces. Braces. Good. So with braces. And I set name, the name of my user, email, email of my user. And put JSON Marshall with my payload. I reset on output. And an error, if happen, if an error happened, I will return my error. If doesn't happen, I will return my output. It's a JSON. Nice. And the two concurrence code. It's only a high overview, okay? My concurrence code. We can set my main function. And I started my first channel. Channeling goal is to communication. It's to share memory to communication between go routines. Go routines are like green threads, sorry, it's not a real thread, it's green threads. So I started to make a channel, other channel result and channel rod jobs. And after that, I started three new workers. Look. Look. Worker one, two, and three. And I set the value for my jobs and set the value and reset the values of my jobs and close all the jobs. So the code of the worker. The worker code is a range of the jobs. And I reset the value from the jobs. And look, then process, kind job. Let's see this. Started to run. Don't disappoint me, goal line. What happened, man? I don't know what happened. So I will show, wait a minute. I will show for you. Because the presentation ran the code and the green go routines, look, it's the code, the same code. Okay. It's the same code. And when run, it's not least. So it doesn't matter. Okay. Continuous. And the concurrence pattern. It is the real concurrence pattern. Okay. In the real concurrence pattern, we do that. We use the sync to synchronize it, the go over teams, okay. I imported my login, an API, two to login, and configs my environment, is my code, and the other code to connect from Redis. It's a real code, okay. My main function, I start my config, I put the log, and after that, I start my Redis poll. And run my goal routine. When I run my goal routine, I call this function, look, I start a way to group here. This code, this variable, will rate all the finish of the goal routines. And I add my goal routine and start an anonymous function to process. When the anonymous function and the diff here command will return, hey, rate group, you can stop it because the goal routine is over. And after that, I call the function process, look, function process here, and I call my process. This will be what? It's a real code to consume from Redis, queries from Redis. I start this to consume a lot of process and recreate the requests, okay. The guys send me a request for goal application, and they take all the requests and made a dump of the request and set all the requests on my Redis and QE on the call. And why did that? Because we need to maintain the older application, and we need to reproduce the real request or my fake request for the older application, the old application. And my goal, I will show the tests. At first, I have a code here, a Java code. It's a Fibonacci, look, it's a great code, a Fibonacci code is fantastic, and why? Because I use this all my life, that's a joke. But it's good only to know what happens, not to return a string. And why I don't know a test with return hello world? Because Java cached the strings. So if I put the same string all the time, I don't test the handler or the process of Java application. I test all the cache of the LLRU cache from Java application. So I put the Fibonacci and I will do the test. The Java application is running, and I have here on WRQ pointed for the test. I will have 62 connections per 10 seconds and two threads, okay? I start the test, and that's it. 36,000 requests per second. Okay, it's the number of the Java application. And the Java application is interesting because when you run other time, many times the Java same faster than the other time. And why? Because the JIT, JIT from Java is really performately and very smart. And it was a few better, like only a little feel better. So I will stop at this and started Ruby with Sinatra, okay, to give API. Started my Ruby application, and I don't use Unicorn or Witski or nothing kind of this. And why? Because if I use Unicorn or Witski or kind of things, I put Isorite on the gill or my handler. It's not a true test because I don't do that with Java and I don't do this with Goal. So I put in only rubric, it's okay. And I will do the test again. The same test and the same port, the same number, the same Fibonacci code. And only to know the Fibonacci code of Sinatra is this. It's this code of the Sinatra application. And Sinatra give for us 300 requests per second. And you can look, yeah, 300 there, requests per second. It's bad, no, 70% of the Internet you use don't do that. It's not, it's great for 70% of the Internet. If you have 50 million users in your API, it's a problem. Maybe the same problem happened with Twitter, but if you do a common application, it's good. And you put unicorns and whizzies and the kind of things will be more performately. And I will see the same with Python and Flask, Python and Flask Fibonacci. The code of Flask is it, okay, the Flask code. And when we look at the test, that I don't, I'm not started, I started that now, 10 seconds, 8,200 requests per second, it's better than Sinatra. And it's really good number, okay? So I will do the same with Tornado. And Tornado is really more performately than Flask. For 10 seconds, oh, the Tornado code, there, it is the Tornado code, okay? This is the number, one and a half, there, looks good, it's a great number. And with unicorn and whizzies, it will be better. And with Tornado applications, I made applications with 23,000 requests per second, okay? It's the max that I want with Tornado. And after Tornado, I will do the same with Go. And start the Go application, and there you do the same test. Oh, God, the connection by 10 seconds, and the code is it. Code of Golang, Fibonacci Golang is it. And was 38, found the request per seconds. But I don't use other thing to go faster than, at now, 39. But we have a problem with Macbooks, and why the problem? Mac has a limit, 4,000 requests per second. So we need to change it to the Pellist code, the Pellist configuration in your Mac to have more requests per second. Yes, it's true, yeah. And because this, we need to do the test with Linux. So Go was performately, and it's the limit, the limit of the Mac. And go ahead with Go. Because this, we have a new project, GLIVE. There's GLIVE. GLIVE is like GLOVE, I think, but in Brazil it's GLIVE. Because GLOBAL LIVE, like GLOBAL VIVO, yeah, it's not so good. It's the part now for microservice. But in the front, we have an engine X. And they send the engine X, the engine X do the redirection of the request for our application, and not to older application. When we have a get, they get a reception on the cache, and read from the cache. And if a post, an update, or delete, reprocess with GoLang, and write on the cache and the queue. The other microservice, Go microservice, or Python microservice, or any other microservice, read from the queue the information. And I have a lot of Go routines, read and write, and read and written on the cache all the time and put on the MongoDB. MongoDB is our new database. And why? I don't know. No, I know. When the people ask me, oh, watch the database you prefer, I spoke, look, I prefer Cassandra. And I don't have Cassandra, I have Mongo. There are all the options, yes, MySQL, okay, Mongo, was my decision. But Mongo is difficult to scale. And when you set a lot of values in Mongo, 300 gigabytes, they slow to give the information. And the get process, the get work is really slow when you have 300 gigabytes. So the solution was worked with this, with a lot of Go routines, consume and write and the consume information all the time. So when the engine X send a request for us, and we take the engine X, we get the engine X, and the request and the put on the cache. And after writing the cache, we return to 200, okay, or was created to 01, to 01. And the stay and engine in the cache is insufficient for us, because the cache is with persistence, time and persistence. So it is our stack, our tools, and G live application. And what we use it? For the handler, we use Pat. And why? Because Go is not friendly, it's not so good to know the verbs like get and the pulse and the put. We use this mixer only to translate these things. Like you do with Flask in a Python application, you say it's a get, it's a get, it's a pulse. We do that with Pat. Negroni is for our meterers. It's only for meterers. The dgo is our register driver, and MGO, our Mongo driver, and AM keep you our connection with ReptemQ, and Godap is to vendorizing the Go code. If you put the repository of the Go, it's the get. So when you do an apply and you will build your code, the Go lang takes all the information from the get, and it's dangerous, because he takes the information from the master. So it's dangerous. It's the best option, you vendorize in your dependencies. Testify, because tests in Go many times are ugly, because you test with if, if, if, if, if all the time. And the testify is you put the assert, assert is equal, assert is okay, and we use this. Go validators is for validation. We validate if a mail is true, or three mail, three names, and the true things are filled. And the go taint is to have a contains, you know, contains in your list, God doesn't have. It's tragic. So I write this library. It's not so good. It's the vendorizing code. It looks like Jen Luck, if you worked with Ruby once, and it's a vendorized code. Look, the revision is the get history of the commit. Okay? It's the testify code to give tests more beautiful. And look at that. When I made a test with testify, I have a, what do I want? I have a beautiful, not so beautiful code, but a friendly code to do many things. Look, I created errors, specific errors to return, and return a red cache. And it is the real code. So the mock of this is the cache test. I mock, look, the mock here, and create the mocks, and use the set up my mocks. And after start the set up code, I will do the Oxford code. If I don't use testify, I need to put, if it's not new, if it's terrible. Okay? And we always use the last stable version of the goal. And why you don't stop it in the version? Because it's not good. It's cool to roll in goal. You change it for the last stable version. You don't use all the versions. And what's the result after change it for goal. Is it? Now, we can registration, all the logic of the register user. We can do with 2,000 requests to 4,000, 24,000 requests per second. Use registrations per second, not request registrations per second. And we change it from two big monoliths to a pool of microservice. Nowadays are, I think, 60 microservices, 50 microservices, kind of things. And we use a lot of, many, many, many, many standard library. It's not so good in goal. Do you use frameworks? Because, look, goal has a big goal, it's a copy of Rails. Okay? Big goal is a copy of Rails. And it's not good. And why? Because you lost the performance of the language. And it's the same for other frameworks. And the many standard libraries, it's easy to deploy because the microservices has one unique center code. And merge is distributed and simpler than you need to merge with a big monolithic code. So, and what we do with the legacy? We have the legacy code run yet. And why? Because it's an application with 14 years old. If you don't want to change this application in six months, it's impossible. You need to maintain the coexistence. So, the request was accepted by the front-end. The front-end doesn't change. It's in Scala. So, Scala said to NGNX, or this service, this guy will be registered in July. Or this guy will be registered in the older application. NGNX did the decision. And he can go to the July pool of microservices, microservices pool. Or he can go to the monolithic application. But you need to maintain the database synchronized. And we did that with more goal applications. The G consumer and the sync. The sync take the information from Oracle and write information in Mongo. And the consumer take the information from Mongo and write information in Oracle. All the time. All the time, go routines, look, and look, and look again. Okay. And I want to start. I want to write APIs with goal. What do I need to do? I recommend a lot. You read effective goal. It's an open source book on the site of the GoLang official website. And there are two GoLang to lose the fear of the syntax. And goal by example is a good option too. And why? Because goal by example, you need, oh, I need to do a mutex. There are an example. I need to do a pool of workers. There are an example. And the goal by example is good. It's by example. And at now, questions? Thank you. My content, if you want to speak with me, you have an, oh, one question there. Hi. Hi. On the side of using Java, Java consumes a lot of memory. So your servers have to, it's more expensive. And what about Go? Yes. The goal application don't have a big consumer for memory. It consumes a process. And if you have a lot of go routines, you'll need more process than memory. Look, I don't, I don't speak about this, but look this. Our stack. At now, we changed it from the path to the fast H2P. Fast H2P is a new option and a new thing of the word. More faster thing of the word to handlers. And they create, this guy creates only two objects in the memory. It's, you can use a sync pool and buffer all your objects. It's an option too. So go, don't consume a lot of memory. You consume more processors, more cores than memory because the routines run your OS threads and it happens. More questions? There are any other questions? Okay. Thank you a lot. My contact and see you later.