How To Use GitHub For Real Software
Let's learn how to use GitHub📅 2025-03-22
Transcript
[00:00] I'm currently the co-founder of an AI software company called bump UPS funded by Google so let me give you perspective on how to create scalable architecture within software welcome back y' as you already know on this channel I go over a lot of topics when it comes to leveraging artificial intelligence in a business and a lot of my content has been centralized around coding out actual software when using AI this content is very much focused on the sense of logic based coding where you don't have to have that much experience in coding and still build out fully functional full stack applications I got
[00:30] an entire front end playlist that's 3 hour and 30 minutes long an entire backend playlist that's 2 hours and 30 minutes long but one thing that's reoccurring throughout those playlists and throughout these tutorials is the idea of building scalable software and more specifically a focus on architecture within software so in this video we're going to go over that topic and I'm going to tell you the difference between a new little startup and a more maturing software in the business world because as we know of AI it will tell you that hey this is the best way to code out an output but in reality if you
[01:01] don't have context of the truly best way you're probably going to find yourself in rabbit holes that are no good so we don't like that let's talk about it so Day Zero just starting you just opened up your IDE vs code cursor whatever it may be you're about to start you're going to start with one repo now I did an entire series here on the back end which you can just I will go ahead and just put in the description down below this is a free code repo that I showed you with a bunch of different functions that just work out of the box this is completely free ready to go just click
[01:31] the link everyone has access to it just to take a real quick step back if you don't even know what a code repo is and what a GitHub is and everything about it let me give you a little bit more context here real quick idea behind this is that on our computer when we code a file that's local on our computer example your laptop breaks and you don't have a GitHub repo that means you lose that code Forever The Way We leverage GitHub and these repos is our ability to have our code in the cloud but this also allows for managing when it comes to pushing out new features if something
[02:02] really just messes up with one of your code pushes you can roll back to a branch I'm going to do another video on this topic but all you need to understand is this and what you've probably seen up to this point when you are just starting out building out of software speed is of the essence your ability to get from dot zero to dot now we have a payment provider stripe API integrated now we have Services now we have XYZ authentication whatever it may be speed is of the essence so therefore using one repo EG actual backend app
[02:32] this is where all the code is associated the front end and the backend is advantageous as in reality when you're starting out scalability is not of the importance so you can have one repo where you're pushing not only the front end changes put an F here for front end but also are pushing the backend changes so whatever you're using you're just pushing towards one repo go go go and that is typical development in the early stages of a startup but here's what happens when you start maturing as a software and basically stuff really
[03:04] becomes real real in the sense of you're making money you're hiring employees and you're just Off to the Races as a quick side note I'm actually doing an entire series on this channel I don't know if it's come out yet or not it might have it might have not I usually schedule these videos out I'm showing you how to hire unpaid interns step by step everything associated with it legal contracts how to vet relevant interns how to handle yourself in interviews there's going to be like a series from Step One to step six or something like that where I show you how we do it internally within our software company so keep a lookout on that as you can
[03:35] hire unpaid interns to work within your software company but before you would do that step you need to do the next part here which is going to allow for scalability for software development so your situation right now is you're deploying to one repo you do mpm build start Firebase deploy it all builds as one big package to prod or QA that in itself as you build a larger application takes a good amount of time because you're building so much code and compiling so much code this is where you go from a mono repo architecture to a
[04:08] poly repo architecture so instead of us having just one little repo we're going to have multiple so boom boom boom what do you mean Corbin watch this as we know in this mono repo here we have the frontend and the backend one of your repos is going to be just the underlying code for the UI call it like XYZ company XYZ UI the only code that's going to be in XYZ UI is going to be your front end code that's it then from there we're
[04:39] breaking down other parts that are a part of your mega repo so as we know from that tutorial from my backend series here one of the functions here was our ability to access open ai's API and do an artificial intelligence type of output this was found in the python functions folder in theory we would take the python functions folder assuming there is a ton more functions associated in Python and create a whole separate repo just for those functions this could granulizer here where maybe you want the
[05:10] python functions associated with purchases as it's on repo and then you want the python functions associated with value you provide the end consumer as its own repo so the idea here is for this example we could just do python maybe we're not going as far as separating the underlying python type of functions which I encourage you to do but assuming we're doing like a r one we could do XYZ company python which then leads into the functions folder here which was JS we could associate with XYZ JS or alternatively as we know from that series that was authentication so we can
[05:41] do XYZ off but in reality we could call this XYZ infra for infrastructure EG the underlying repository will need to run no matter what throughout the application development process what do I mean by that let me give you an example once I get this example I'm going to break down the advantages of going to a poly repo the idea is this let's say instead of just doing like XYZ python we do like XYZ purchases and this is like all of our functions that are associated with purchase logic EG allers stripe Epi documentation and stripe
[06:12] files what we can do now in theory is for us to commit a change there's going to be certain repos that we need access to to actually make the change you don't need access to the entire application to make the change maybe to a stripe situation so what this means then for the develop is that when giving access to the underlying repo we could be like okay well you need to make changes to purchases which means that you'll probably need access to infra you'll probably need access obviously to our repo associated with purchases and then
[06:43] maybe we want to provide access to the UI as well so we can load all three of these and then make the change push it to the branch notice that within this logic they're not getting access to XYZ python because it's not necessary for the change that are required from that individual so therefore let's break it down of why this is fundamental so first major reason why this needs to happen for IM maturing software is deployment time what this means is that when we were just doing a mono repo it would
[07:14] take much longer to deploy the entire application because we are just running through all the code now when we make a change to maybe just infra it's only going to be compiling infra code therefore we're going to be deploying a lot faster to QA and prod now right now you might like Corbin who cares it only takes me like 20 seconds to deploy trust me you build bigger software applications that are a lot more complex deployment times can get very lengthy I mean I've heard stories of deployment times getting to 10 to 15 minutes long because of that much code so deployment
[07:46] time repo management if you have a team of 12 individuals all working on the same software and every single one is creating a branch for the same repo it can get messy really quick although if we break that down to where maybe all right three people in the team are going to be working on XYZ python repo okay four people on the team are going to be working on XYZ UI it separates it it makes it a lot cleaner and the code doesn't get really nasty really quick therefore scalability is huge here because if you have a team of 10 to 20
[08:17] software developers oh no you don't want one repo trust me on that No Mono repo which leads us into the next major reason why which is security we already know this but code is extremely valuable that's why a lot of software companies we call them unicorn companies because the fact of their evaluations are nowhere near the recurring Revenue they're getting either annually or monthly but because it's software in itself software can be applied across the world anyone can consume it if you build it correctly we need to ensure we
[08:48] have security when working with multiple employees you don't want to give just one repo which is your entire code you're basically you ever seen SpongeBob you you know like crusty Krabs secret formula like you don't want to give the entire secret formula away you need to split this up into multiple repos as shown here as the individual that maybe is on the backend team will only get access let's say there's like eight repos that's compartmentalizing your original one repo eight repos backend team or backend employee needs to access
[09:21] three of those repos good to go proceed let's get some work done let's build let's have fun not they need access to all eight there'll never be a situation where an individual will need access to all eight unless you're obviously the owner of the underlying software company there are more reasons why poly repos are amazing but that gives you perspective on what creates scalable architecture within your software therefore let me end the video of this your next question might be Corbin when do I make this transition to each their own in this perspective but I say you stick with the mono repo as long as
[09:53] possible as you're just going to be able to build a lot faster it's a lot simpler you don't have to deal with all the complexities of having multiple repos just go go go and go your transition from monor repo to poly repo needs to occur when you start hiring people or onboarding more people to work at your company this goes to say that let's say You're Building out a software and you have one other co-founder or two other co-founders I still encourage you to do monor repo I wouldn't necessarily transition to poly repo unless one your software is making a ton of money so if it is one person and you're making a ton
[10:24] of money then yeah you need a transition to poly repo but in the short term stick with monor repo but keep everything you just learned today in the back of your mind when you plan on making that transition onboarding employees and you can check out a whole playlist of how to do that on this channel here then switch a poly that cover today's video make sure you leave a like is completely free I'll see you in the next video mono poly two random videos that's my face I'll see you in the next video