What Large-Scale Software Looks Like

how do you write large scale SL Enterprise style software in general but also in nextjs what are the patterns that separate regular software from Enterprise scale software and what does that even mean you and I are going to take a look at what Enterprise means in practice I'm going to tell you from my own experience on Enterprise and startup using a boiler plate as an example that just recently came out and went pretty viral on social media a production grade herbo repo template for nextjs apps what does this even mean production grade we're going to

see that in a second together a mono repo template designed to have everything you need to build your new SAS app as quickly as possible and that includes authentication nice okay we're going to see how that's done billing using stripe for payments right so users can subscribe to your Pro Plan analytics and this part honestly the analytics the observability is really well done in this app as you'll see SEO a database omm and much more stuff right it's hard to articulate feature flags and all that stuff it's all in here and it got like 2,000

stars now the background behind why this got so popular so fast this turbo report template is this tweet right here right it comes down to this pretty much it's a tweet from the guy who runs versel right the CEO his name is G and he made a tweet about this a production great monor repo First full stack nexs template and then there's the command to just initialize your project with it very thoughtfully engineered this is true we're going to see that and documented it covers all DB and orm payments docs right docs wasn't listed before

on the website but documentation is also included a Blog which is one of the most interesting Parts emails and even feature flags and dark mode there is so much stuff going on in the starter point that it's really hard to get a first look like a lightning fast app template start building your app with a Shad CN UI template that's already set up with everything you need now I'm a bit confused here why does a UI Library make or app fast like I don't see the connection here maybe it's just faster to set up the

UI maybe that's what they mean and what I find probably most interesting about this repo is this right here the crossplatform API because this is something you'll actually see in Enterprise context which doesn't mean it makes sense in your app we're going to get there but basically we are splitting our API into a micros service for many different apps with a types saave database orm which is Prisma now this is the most interesting part we're going to get there but let's quickly finish this feature section what else is in here we got emails using react

email we got a types saave blog using a library that I have never heard of before but that's actually turns out to be pretty cool which is called content collections because what content collections allows us to do is is the following let's go to the hosted website right here that I started up in the background and this has a Blog and what this Library allows us to do is to basically write blog articles like this one understanding gdpr a complete guide for businesses which just serves an example as an example right it lets us write

these in MDX which is markdown XML kind of a react markdown syntax so for example this gdpr article is completely type safely written in MDX and then converted into a Blog article at build time right not at runtime at build time which is really cool so it's immediately there as a static really fast blog article usually you would use a library called content layer for that but little history on this MDX library is it got deprecated eventually it stopped being supported which is why people moved off of it it was one of my favorite libraries

of all time but yeah unfortunately it didn't make the cut and eventually it got discontinued it was lightweight it had a really really nice DX so does this new library and it's blazing fast so you know it's good right it got a fancy web page so that means it must be good we have documentation built in maybe you need it maybe you don't need it it's already in here um that's a common Pitfall right if you don't need something well you'll still get it in this template right and a visual database editor which is the

Prisma Studio wow those are a lot of features and a lot of tools you can see the tools just flying through here that are used in the stack like recent content collections for the markdown that I just told you about clerk for off post talk for um analytics radic UI for UI design Sentry for observability CM DK fuma do I have never even heard of that to be honest arcjet for security Google analytics and that's a positive and a negative at the same time there's just so much stuff in this starter point which is great

to learn from but it's also kind of the problem that I see with this so let me get to this the most interesting pattern that I want to talk to you about is way up here the micros service pattern for the API and the reason why this is so interesting is because you'll actually see this in your first Enterprise project very very likely right so basically how this works is normally how we write an API in nextjs because this is a I've already got the drawing tool open here oh and by the way yeah I

just made a little list like why should we even care about this what's in here but we already went through that um so anyways how we write a nextjs API and this is assuming we are just building a web application and not a mobile app right basically how this works is or project code so your whole jsx your react components your lib folder everything lives inside of this nextjs project right it's defined in here and your API that serves the requests from the front end lives in the same nextjs project right it's just another folder

in your project and then the project code the front end can interact with the API to request data and the API sends that data back to the front end and it all happens encapsulated in the single nextjs app in this microservice architecture that this app does really well or the starter Boer play does really well we create an API microservice what does that mean it's a principle of reusability this microservice architecture and just because I know you're too lazy I Googled it for you so what this means is a microservice architecture consists of a collection

of small autonomous services so what that means is your project code does not know about the internal workings of your API nor does the API really know which project it is serving and that has benefits and downsides so how this works is in this boiler plate example or also in Enterprise code because we did it a very similar way when I worked in Enterprise just with fastify as a back end and not nextjs that is quite unusual to see a nextjs backend in Enterprise for my experience the difference in architecture is this the API is

no longer part of anything related to our project code the project code is completely on its own and actually let's call this micros service AR architecture right you you get the point the project lives completely in the dependently and so does the API they do not know about each other but the front end code can still request data from the API and the API then sends that data back to or front end and that has the added benefit let's rename this to nextjs by the way that has the added benefit of very easily being able

to introduce new requesters for example a mobile app because if your API is super tightly related to your nextjs project let's also rename it just to nextjs here if these are super tightly coupled then how are you going to introduce an app to this the app would have to exactly match the API structure that you enforce through nextjs and that's unlikely right in a real world project that's rarely the case so if you split up your API to be a micros service an autonomous service that is easily compatible of course depending on how you design

it but if you design it well then it's easily compatible with your mobile app and can serve every app that you have so for example in the Enterprise that I worked in we had a separate IOS app along with a react front end we had a fastify API which is a node.js language I was actually really surprised because my co-workers were like super experienced like 30 years of experience in coding and they like JavaScript on the back end I was surprised to see that but it was fastify and then we also had an Android app

all written in Native languages and not something like flutter but this was in Swift and this was in like C++ I believe or whatever you make Android apps with and the benefit of this microservice architecture is that each app can now be served to and from or API right we can request data and that data is then sent back to every single app also including Android of course right this microservice architecture is exactly what's happening in this app in this boiler plate right so let's take a look at how they implement this just by the

folder structure it's already really easy to tell we have a top level folder called apps and in this apps we have our microservices those being the API the app which I assume in this case means the mobile app and then web which is our nextjs website in practice the API is its own folder it contains an app directory with all the logic that is handled by the API like cron jobs health checks right how does a health check look like basically it's just this right we can make a request to this API and check if

it's still running because serverless functions run in V8 isolates not on cloud flare workers but in general they're isolated I I honestly don't think this makes so much sense because usually this comes from a background of we're checking if the server is down or not but if each function is completely independent in server this anyways we can run Chron jobs where we just create a page and delete it again to check if our database is working this does make a lot of sense this is real world actual like this is a thing right where we

just check if the database is working on a schedule like 15 minutes 30 minutes whatever it is so you're instantly notified when something doesn't work that is very very real work like and we also have web hooks for secure implementations for payment with stripe and for authentication with clerk where all events are handled for us these are more events handled than you'd likely have in a real world app I my own SAS and I handle like three events or something but this boilerplate handles all of them and one other thing I want to talk to

you about is the abstraction to packages and this is um a big point for debate you'll see this in real world apps like for example a open-source um app that takes this approach of reusability via packages is called dub right it's an open-source link management infrastructure tool and it's by far not the only app using this kind of infrastructure that I'm about to show you but it's good and bad at the same time to use this reusability approach but I want you to know about it because it can be really really powerful if you use

it right how it works is basically we have our apps right in the case of dub this is just the web app in the boilerplate case that's the web app and the mobile app and we have packages and these packages are basically split logic from the main apps like styling configs for example here with Tailwind shared utilities and shared UI things and so on you get the idea right so if you want to share pieces between your mobile app and your web app for example then you can use something very very similar to a micro

service architecture and just replace the API with for example a UI library right if you have one design system you want to use it in all of your apps in nexr IOS and Android so they all look the same so you don't have to do sting work over and over right and how we achieve that in practice is by something called packages you can see right here we have our apps and packages just like in the open source repo I just showed you where we split up analytics of even or database right it it makes

sense in this case but I'm going to get to why this might not be the best idea environment variables feature Flags observability styling with tailwind configs and so on now this this can be a really good idea because what this allows us to do is to basically use the same database the same Prisma orm client throughout all of our services like our app and web app and so on so we always connect to the same database we always have the same data in our API but what it also means from a logical standpoint let's take

a look at this we got to ask ourselves first off what is different about enterprise software what makes enterprise software Enterprise and this is a really big talking point right and if you ask 10 people probably you're going to get 10 different opinions so here's mine right what Enterprise means for me is I've worked at one Enterprise company it means your code scales but probably not in the way that you think I mean this what I don't mean is your code scales to more users right that's not what I mean not user related what I

don't mean is you can support a sudden influx of a million users in your servers Auto scale and everything Auto scales right that's not what I mean what I mean your code is written in a way where it's easily and this is the main point easily extendable where you can easily build new internal microservices on your existing code architecture this also means abstraction you are really good at abstractions or you get really good at abstractions if you do enough Enterprise software because you're kind of forced to because the code bases are absolutely huge you're forced

into writing nice abstractions that allow you to build new microservices on top of your own abstractions because the thing is in Enterprise it's very likely that the code has evolved over years if not decades right that is not uncommon to have code that is decades old in Enterprise software and as you might have noticed the template repository plays exactly into this using reusable packages in your app in your web app and so on it's easily extendable and easily reusable this is not the most practical if you're starting a new app though because imagine this right

in which scenario do you need to support a web and mobile app that is the main qu and that's a really long question man here in which scenario do you need to support a web and a mobile app at the same time while starting your project you're just getting started and you need both you need web and mobile realistically when is that going to happen usually it doesn't usually the way you start is without a mobile or without a web app but either one right very very rarely do you start out with both because fundamentally

that's a big Financial Risk to start out with both usually the path is to go with a web app first I'm biased I'm a web engineer maybe you're more on the mobile side but the point is you only start with one until you find product Market fit if users do not care about your web app why would you bother making a mobile app and vice versa right and in that case in this logical argument that I'm making here splitting stuff up into reusable packages is a good idea if you're in established Enterprise but it's a

really really bad idea if you're just starting out because if you have a single app just a web app just a nextjs app you do not need microservices in the way that they're included here in this template repository this architecture only makes sense for this architecture if you only have a nextjs app the splitting up of your UI of your database and so on into multiple folders into reusable packages is pure maintainability overhead there's no benefit because you're making reusable packages like the database that you do not even reuse until you have product Market fit

and at that point you'll probably have the the revenue to then refactor into this kind of architecture for usability right so what I'm saying here is you start out with a web app and if you go for a Enterprise kind of architecture this is completely unnecessary right it's really nice to learn from to get an idea how Enterprise does it how Enterprise services are scaled and built and architected but it's far from being the best starting point for your own apps chances are this right here is the best starting point for your own apps and

mine as well right simple apps until you find product Market Fit until you notice that hey users actually want to buy your products and then the transition is more into Enterprise architecture that's what it means to be enterprise software for me and of course your interpretation might differ but that's the best approach in learning from this repository right take a look at it take it with a grain of salt because it doesn't mean you need to start this way but getting an idea of how Enterprises architected this is really really nice for so I went

ahead and linked it in the description for you and that about wraps up my experience with Enterprise software I work at a startup now I eventually transitioned over from Enterprise to Startup because I find the environment more fun but working at Enterprise can be really really nice for your learning process right how do things work at Large Scale whatever that means for the company you're working at that's going to be it for this video and I'm going to see you in the next one until then have a good one and bye-bye