Hey tech late here and welcome back to another episode of the tech lead. I am the tech lead, and this is coffee time with the tech lead. We have a special guest here. I think his name is Clement or something anyways. My name is detected. I am the tech lead, I'm drinking instant, coffee today, Clement. What are you drinking over there? High tech lead. Yes, my name is Clement, or at least they think it is, and I'm drinking, maybe instant coffee. What we're going to do today is we're going to learn about how Clement had built up algo expert diode. This is an entire web application, fully functional in production with thousands of active users. He put this up with a co-founder we're going to go from back-end through front-end and learn about how he put this together, and I think that this is an incredibly valuable skill Clement, whether he tell us about what is algo expert and how you've put this together. For sure algo expert, as some of you might already know, is a platform that gives users a list of curated algorithm interview questions right now. We have 65 for every question. You have a coding workspace where you can code up your solution and whatever language you want out of five popular coding languages, you can run that code against custom test cases, see video explanations and so on and so forth. This sounds absolutely amazing. Now is there a way that our viewers will be able to access this website with some kickbacks for myself, I'm thrilled that you're asking this tech lead. Actually there is, I think, if you go to algo x4 dot, io slash tech leads slash. Tech lead. Let'S not forget that slash tech lead, your users will get a discount. That'S absolutely amazing. Did you guys are here that you'll get discount so check it out I'll, go expert, io, slash tech, lead ace, your next interview. Now? Why don't you tell us about your back-end, because when I first heard about this back and it sounded completely over-engineered to me, I could probably build algo expert i/o in an afternoon using PHP and JavaScript with html5. But how are you able to build this all right? So it's very interesting that you say that actually there are very specific reasons for which we built the website. The way that we did, although expert, runs almost entirely on DCP Google cloud platform, we run on three virtual machines. Two of them are: has 16 cores. One of them has eight pores, and then we use kubernetes to kind of work her straight and manage all of these VMs and all the containers that run on these VMs. Okay, can you give us a quick overview for those of us who don't understand what is kubernetes, if you think about an application right, you've got a lot of different services that each rely on different libraries, different technologies, different versions of these libraries containerized applications allow you To have sort of independent, isolated containers for each of your services in your application and kubernetes is a great way to kind of manage all of these containers at scale reliably and easily, and google kubernetes engine, which is the the platform that we personally use, allows you To do that extremely easily, like they handle most of the sort of administrative part that you don't really want to handle as the developer cool and then what are you using for your back-end? Are you using Python, PHP, laravel, Django, nodejs yeah, so there's an interesting story behind that we started out by using node.js and Express, and then my co-founder Antoine, who was in charge of building the backend, realized that all his expertise was in go, and so we completely Scrapped our nodejs work went with a pure going backend and that's what we have now. That is fascinating, because these days, you don't care all that often about completely go back ends, usually they're, using mostly for micro services. How is that working for you that actually works? Really well for us, because all of our back-end services are split by functionality, so we have no are off back-end service. We have our subscription back-end service. We have our problems back-end service, so it really works out well for us and I think that's great, because you can really choose any language, any stack that you want. The key is to just ship the product and make sure that it launches you don't necessarily have to be always following the hype train and using what other people are telling you that you have to use necessarily agreed. I think the key is do what works for you so long as it's reasonable. Now, one of the most difficult parts of any app occasion is going to be in the database. The database is notoriously difficult to scale. The general went back and usually you can scale that by throwing money at the duplicating many machines using a load balancer the database, sometimes it's more difficult to manage and it is a major pain point I found for myself. How do you manage your database? So fortunately, we live in a day and age, where you have amazing cloud providers like Google cloud platform, Amazon, Web Services or Microsoft Azure. That kind of a handle a lot of the difficulties or complexities that come with databases, for you know, replication, backups, and all that we started out by using Google cloud data store as our main database. What does medical cloud datastore cloud? Datastore is no SQL database. That scales is reliable and is very simple. To use. The really big selling point that they had for us when we started out was that they have a really nice UI. In other words, you can see really clean tables of all your data. Now one of the annoying parts of data store that actually came back to haunt us is that data store only has eventual consistency, and so for some of our services. We needed strong consistency in our database, and so we ended up migrating to Postgres for some of our services, so this is fascinating. What the eventual consistency is is when you write to a database, it's not necessarily guaranteed to be written immediately. It could be written later on and then, when you read it, you may get a stale value. Eventually, though, you will get the proper value. The great thing about Google Cloud, datastore and services, like these no sequel databases is that they can scale very easily and you don't have to manage that scaling by yourself. You don't have to set up master master replication master slave backups. All of that stuff. I think that that is one interesting thing about using off-the-shelf database provider services like this. So it sounds like that. You'Re using a lot of third party products like you're using kubernetes darker Google Cloud datastore. How many of these products are you buying from and then gluing them in versus? How many are you in the house just from scratch basic components for the more sort of nice targeted services, we've actually built them in-house to save a lot of money? So the two big examples that come to mind are number one: are code execution engine so on our website. You can type your code and run it against our custom test cases and Java C++ Python JavaScript pipe going, and similarly we have a sort of continuous integration. Continuous deployment system built for feature releases and our testing and that's also built in-house, so we're saving a ton of money. What is this code execution engine? How are you setting this up and how do you test it? http://www.bat-editions.net/how-to-boost-instagram-story-viewer/ of a code, execution request? Is this someone is on the UI and they press run code. The UI makes a request and we have load balancer ng inks, that will route that request to a specific docker container that it knows of you know, maybe like the JavaScript docker container, that JavaScript docker container is gon na, say: okay, is this user able to send This request, you know we have like rate limiting services, that container is gon na reroute the requests to another container and their optimizations there to like share file systems or certain mount points, and that other container is gon na then have like all the libraries or things That needs to run code in that particular language. It'S gon na run it it gets the response, then it gives the response back to container number one gives it back to the UI. What does your rollout process like? How are you releasing new features? Are you just coding on prop, or do you actually put this onto staging and then roll that out coding on prod tank lead? That'S what I do. I don't work mistakes to a night code, so I can just go straight on prevent it's okay, but for other people more normal people. I can understand why you may want staging for us mere mortals. We actually have you know different environments, so we have three environments. We have a QA environment, a staging environment and a prod environment, at least for the UI, for the backend. We have just staging and prod, and then we have this really cool, continuous integration platform that we've built in the house. That makes it such that any commits. We push up, gets automatically tested or at least leap. The code Mason's been affected. If we make a change to the UI, all of the UI tests are gon na be tested, and it's been really really nice for us and it makes it such that we can deploy new features at a moment's notice. I'Ve actually deployed stuff to prod from the train from the subway from my phone with like zero downtime on algo expert, which has been like super nice for us. Okay, I guess, is it good that way I probably would have just coded on prod, though that works, and what happens if one of your tests were to fail. If our tests are running and one of them fails, we actually have alerts via slack, so we use slack bots and we get paged and we can immediately see like what's going on now how about your front-end? What are you doing for that? So for the front-end? We use react and redux. The main reason we used react is that's what I was really comfortable with. I hadn't worked in angular at the time that I started Al Gore expert. Now I have to be honest. I still think I'd probably use react. We also use Redux as our sort of state management paradigm. Redux is super helpful for when you've got like relatively complex states, and you want to be able to access them anywhere in your application, like you know, is the user logged in or has the user purchased? The product already for testing we use just an enzyme, very popular frameworks with react, and the one thing that I do want to bring up is the language we use. So obviously we use JavaScript right. It'S unfortunate that at the time that we started algo expert, I had no experience in typescript. For those of you don't know, typescript it's a superset of JavaScript, it's basically a typed version of JavaScript. It is amazing. I cannot recommend it enough. I'Ve also heard very good things about typescript. It'S a huge effort to migrate the entire code base to the typescript that we don't have the resources to allocate to that right now, but I wish we had been able to Clement. Do you have any additional tips? Last minute messages that you would like to give to anybody else here who is considering building out their own tech stack. I think I have three things to say: number one is figure out what are the priorities of your bid and build stuff? Accordingly, number two is use the technologies that you feel comfortable with this echos. What you said at the beginning, Tech we'd, don't necessarily follow the buzz just because it's the buzz and the third thing which is kind of the opposite of that is, do be careful with certain very crucial design. Decisions like that may come back to haunt you. The fact that we started out with Google Cloud Data store that was only eventually consistent, started, causing major problems recently, and we did have to change that overall. I think this is great advice. The most important thing is that you guys were able to build this product and just moving the product forth is always going to be your highest priority without a product. You don't have anything so don't go too hardcore on the tech and forgetting about the product. Well, I think I'm almost done with my coffee. That'S my cue to leave. Is there anything else you want to say yeah. Just don't forget, I am the tech lead they'll. Do it for me, if you liked the video give it a like and subscribe and I'll see you next time, bye,