@@minenandha Production should be stable (probs a minimal requirement for all real apps) - Enterprise should be designed around requirements of large organizations (not required for scrappy startups)
@@minenandha in layman terms, production-grade is the foundation, built to work reliably; enterprise-grade is the full infrastructure, designed to scale, integrate, and secure complex needs.
Awesome video- I’d love to see you make another video regarding the things you touched on that are in production apps (health checks, event management) and more importantly how to make that extensible across your app. Currently working on a startup, and I feel that’s a knowledge gap I have at the moment. Anyway, thanks a lot for the value in this video!
I‘m still not sure how to feel about MDX files for blogs. Often times the content creators are not developers, which usually means a headless CMS should be used instead of static files in the repo
I can confidently tell you that I have successfully introduced MD + MDX (MDX with careful choices) to non-technical stakeholders and if you sell it right they will absolutely see and appreciate the benefits. And that was BEFORE there was the tooling like there is today (drop-in rich text editors for web, sexy desktop apps, etc.). Consider their goals and their UX like any software; if you make their work easier they will appreciate your solution and adopt it. You might also be surprised that they are like a mod in some forum or something that uses MD and they already know it. These days its very widespread.
Its so great that Josh continues to push his career forward while keeping us in the loop. Usually, people either stop their career pursuit to continue TH-cam, but Josh pushes his career to push his knowledge of real world engineering and being up to date. Then shares it with us afterwards. This is rare and I'm really appreciative that I have access to the thinkings of an engineer who's deeply involved in the industry and not detached. Thanks a million!
I don't think this is microservices since microservices is about working in independent repos for independent deployments of each service. But definition is debatable. This is more like a monorepo with multiple services
One factor not mentioned here is the caching benefits of Turborepo that come from splitting your app into microservices. My mid-sized Next.js app experienced a huge improvement in build and test times after this separation, due to the caching layer Turbo provides.
My company is one case where web and mobile apps are needed from the start. Users go through the web app while service providers on the field benefits from a dedicated mobile app. Same use case can be extrapolated to a lot of similar business models.
Facts. I was actually looking for a stack similar to this but its choice of auth provider and database orm doesn't suit what i am working on. Thanks for the reference to t3 turbo. Quick question have you used t3 turbo but with lucia auth ?
Another cool starter to look at. I really appreciate your videos! Personally I disagree "Production Grade" can be applied to everything especially where there's a critical auth dependency on on a money-burning VC backed startup that is still developing its product and has yet to support features for auth that established businesses expect from an Okta or AWS. Many would disagree on Prisma being part of a "production grade" equation as well especially depending on the requirements (definitely NOT suited for any company that puts data at its forefront). Its nice that this one has some basic thought to observability and feature flags even if they are minimal. It does kind of feel like every little feature in this thing is dependent on one subscription service or another.
Nice review! You're exactly right on the API as a microservice. I split it out so it can handle non-application services like background jobs, webhooks, etc. (doesn't make much of a difference on Vercel as they're all independent pieces of infrastructure) but also because if I were to spin out an Expo app for mobile devices, I'd prefer it to contact a dedicated API microservice than the main app.
We'll also have more package abstractions over time, making it easier for people to swap out certain providers e.g. @repo/auth is useful for swapping out Clerk -> Auth.js without touching the apps.
We'll be splitting more packages out over time to make specific providers easier to switch. For example: repo/auth makes it easy to switch from Clerk to Auth.js
My definition for “enterprise” is similar to yours. It needs to support scaling. Not scaling users. But scaling employees/developers/internal growth. Everything has its own team, so things are abstracted so that the thing can be used easily by someone not it that team, but the trade off is that it’s much harder for someone not in that team to build on the thing itself.
I think Adonis JS has already set the path for something like this for Node JS enterprise grade projects. They mostly build their packages themselves in house instead of relying on 3rd party packages here and there.
The apps/app dir is not for mobile. it's the actual web app template that makes use of clerk, shadecn/ui, etc. but the fact that josh mentioned it made me curious. is it possible to include a mobile version app like that ?
nx repo is much more advanced i guess , but harder , so does the bazzle . they are enterprise grade , while turbo is good for small agencies , and self sufficient apps
I understand what you are saying - But I don't see the downside of having the code split into packages? looking at the folder structure - Everything seems more organized? Even if I am not building a mobile app - The folder structure looks great - and just having them split into folders seems like the correct thing to do? Am I missing something?
Almost all apps need the same reusable boilerplate functionality like Auth, Analytics, Payments, etc... so it makes sense to extract that logic into packages, then easily reuse it when bootstrapping a new project under the apps folder.
As a C student, wouldn't just be easy to do it like we've always done and use a service like strapi build all your api, and connect it to the front-end decoupling the frontend and backend? What is different about that concept?
Out of interest if you would hope to get to mobile down the line, would it not be best to start from a position where that could be possible? It's all hypothetical and down to the project of course but what is the bigger burden; the initial abstraction setup or having to abstract an existing project.
That doesn't make it enterprise. Its easy to say "X Brand" uses a framework when it could just be for marketing or docs sites vs. anything critical to core product.
I thought you would give us a complete walk-through of this repo and explain the setup etc... I actually requested the creator of this repo from the same tweet he did agree to do a video but you know.... these guys.. I think they're already planning to add more features to it
Honestly its pretty minimal and nicely laid out skeleton of a project. Simply running down the list of items in the apps and packages directories should tell you a LOT. If there's any piece of the puzzle that doesn't make sense for you click into it and search for what imports it. Kudos to them for an intuitive project layout and clear descriptive concise names. A thing that's missing that I would require if managing a project that would also help you answer a lot of questions is for every app + package to have a README that at a minimum has a topline explaining how it fits in and identifies any special dependencies and third-party services or API's and what's required to get rolling with them both for dev and production (+ direct links to relevant docs + URLs). I never assume the dev is a TS ecosystem fanatic nor somehow knows what some trademark brand name service actually does. This helps onboard devs way faster among other benefits.
@furycorp I just started learning monorepo and turborepo a couple of weeks ago. So yeah wanted to have more in-depth details as you mentioned a README would be great. For instance I wanted to know the reasoning behind having the UI as a separate complete app instead of having it as a package.
@@dreamsachiever212 generally in a monorepo the popular convention is that "apps" are things that are deployable whereas "packages" are libraries that export code for import by other apps and/or packages in the workspace (i.e. like all the public packages on npm). Big Picture: the apps and packages directories are only a popular convention: the directory names "apps" and "packages" are actually completely arbitrary. With pnpm workspaces you can organize your workspace however you see fit. pnpm reads `pnpm-workspace.yaml` for the list of directories to scan for packages to consider as part of the workspace. For example some people like to define a separate "configs" top-level directory for packages that export shared config files so they're not lumped with other "packages". As another example some people prefer "libs" directory name to "packages".
Yeah I'll record something in the next week or so. I'll be adding more features, but very carefully. The line between useful and overcomplicated is a fine one.
Microservices ? How … often theres a confusion on serverless and microservices. While they can be used together usually microservices have well#defined boundaries that encapsulate end to end business logic , each service is independently deployable (for which part you often see it ship with its own database) essentially a black-box. In the repo we have a lamda - cool but lets not label it “microservice”
Enterprise software with Prisma? Hell nah, in my own project compared it to a medium sized query, it was 2x slower than raw sql. Kysely has the performance and typings and you can use prisma schema
@ i only search about it i have no experience but for what i understand it is something that you can wrap your next js app and it will also compile to mobile but like i said i have 0 ideia how it works since i haven’t reach that phase yet
Yeah I like Next.js, but it lacks bunch of things on backend side to make it even production ready (let alone enterprise ready) for backend work. For frontend work it's pretty good, but backend not so much. It just lacks so many basic features to be a full app building framework. This boilerplate is unfortunately just another boilerplate that combines bunch of SaaS software together. At least it's free and people behind it are not trying to charge few hundred dollars like I've seen some others do.
@@ramongodas You costumer will care when everything is slow af. Your wallet will also care when you are spending 10x more due to overfetching, multiple roundtrips and what not.
@@dvillegaspro it encourages devs to do things that actual DBA's wouldn't do and break postgres conventions in favour of TypeScript conventions. Definitely not good for any actual business app where data is the lifeblood of the business. Imagine blocking an army of data science + analytics, business analyst, DBA, and IT people (and their preferred tooling) because some JS/TS dev picked something that suits only them. You're also always missing tons of postgres features that are central to real-world enterprise apps but Prisma doesn't support. Prisma, Drizzle, and others ALL have issues with their DSL's for defining schemas: they mimic SQL but subtract features. For example you can't actually follow best practices as documented by postgres with either because the schema definition language doesn't support those features. In fact these things will auto-generate schemas that have items on the "DONT DO THIS" list from the official postgres docs.
Production-grade is NOT enterprise-grade. Let’s make that distinction before it becomes the foundation for many people!
How exactly? Care to explain?
@@minenandha Production should be stable (probs a minimal requirement for all real apps) - Enterprise should be designed around requirements of large organizations (not required for scrappy startups)
@@Ivcotayou put it well buddy
Exactly
@@minenandha in layman terms, production-grade is the foundation, built to work reliably; enterprise-grade is the full infrastructure, designed to scale, integrate, and secure complex needs.
Awesome video- I’d love to see you make another video regarding the things you touched on that are in production apps (health checks, event management) and more importantly how to make that extensible across your app.
Currently working on a startup, and I feel that’s a knowledge gap I have at the moment. Anyway, thanks a lot for the value in this video!
I‘m still not sure how to feel about MDX files for blogs. Often times the content creators are not developers, which usually means a headless CMS should be used instead of static files in the repo
I can confidently tell you that I have successfully introduced MD + MDX (MDX with careful choices) to non-technical stakeholders and if you sell it right they will absolutely see and appreciate the benefits. And that was BEFORE there was the tooling like there is today (drop-in rich text editors for web, sexy desktop apps, etc.). Consider their goals and their UX like any software; if you make their work easier they will appreciate your solution and adopt it. You might also be surprised that they are like a mod in some forum or something that uses MD and they already know it. These days its very widespread.
There's definitely pros and cons, I've been thinking about switching the default to a CMS and adding content-collections as a migration guide instead.
Its so great that Josh continues to push his career forward while keeping us in the loop. Usually, people either stop their career pursuit to continue TH-cam, but Josh pushes his career to push his knowledge of real world engineering and being up to date. Then shares it with us afterwards. This is rare and I'm really appreciative that I have access to the thinkings of an engineer who's deeply involved in the industry and not detached. Thanks a million!
I don't think this is microservices since microservices is about working in independent repos for independent deployments of each service.
But definition is debatable.
This is more like a monorepo with multiple services
One factor not mentioned here is the caching benefits of Turborepo that come from splitting your app into microservices. My mid-sized Next.js app experienced a huge improvement in build and test times after this separation, due to the caching layer Turbo provides.
My company is one case where web and mobile apps are needed from the start. Users go through the web app while service providers on the field benefits from a dedicated mobile app. Same use case can be extrapolated to a lot of similar business models.
Please make a project tutorial based on this repo.
finally someone understands what scale actually means and the focus on longevity not building throwaway pocs
This repo reminds me of the T3-TURBO stack. Just with questionable features
Facts. I was actually looking for a stack similar to this but its choice of auth provider and database orm doesn't suit what i am working on. Thanks for the reference to t3 turbo. Quick question have you used t3 turbo but with lucia auth ?
Another cool starter to look at. I really appreciate your videos! Personally I disagree "Production Grade" can be applied to everything especially where there's a critical auth dependency on on a money-burning VC backed startup that is still developing its product and has yet to support features for auth that established businesses expect from an Okta or AWS. Many would disagree on Prisma being part of a "production grade" equation as well especially depending on the requirements (definitely NOT suited for any company that puts data at its forefront). Its nice that this one has some basic thought to observability and feature flags even if they are minimal. It does kind of feel like every little feature in this thing is dependent on one subscription service or another.
"I know you are too lazy so I googled for you" He read my mind
Nice review! You're exactly right on the API as a microservice. I split it out so it can handle non-application services like background jobs, webhooks, etc. (doesn't make much of a difference on Vercel as they're all independent pieces of infrastructure) but also because if I were to spin out an Expo app for mobile devices, I'd prefer it to contact a dedicated API microservice than the main app.
The /health route on the API is more of a stub than anything else, but it's useful for uptime monitors to check if Vercel itself is having issues.
We'll also have more package abstractions over time, making it easier for people to swap out certain providers e.g. @repo/auth is useful for swapping out Clerk -> Auth.js without touching the apps.
We'll be splitting more packages out over time to make specific providers easier to switch. For example: repo/auth makes it easy to switch from Clerk to Auth.js
My definition for “enterprise” is similar to yours. It needs to support scaling. Not scaling users. But scaling employees/developers/internal growth. Everything has its own team, so things are abstracted so that the thing can be used easily by someone not it that team, but the trade off is that it’s much harder for someone not in that team to build on the thing itself.
Who came here to see if his code outperforms enterprise projects-and confirmed that, yes, it does.
I think Adonis JS has already set the path for something like this for Node JS enterprise grade projects. They mostly build their packages themselves in house instead of relying on 3rd party packages here and there.
Yeah, but almost no one uses adonis
Valuable content..keep up the good
So basically it's speed of development vs clean code
Without clean code there's no speed of development. Shitty software leads to slow development time.
You should check out Domain Driven Design once.
I'm loving the Convex V1 template 😊 right now
I would not take advice from people that move useless things to production and not actual people rely on them like this guy.
The apps/app dir is not for mobile. it's the actual web app template that makes use of clerk, shadecn/ui, etc.
but the fact that josh mentioned it made me curious. is it possible to include a mobile version app like that ?
You could probably spin up an Expo app in the `apps` directory and run it on Turborepo. You could only make use of a couple of the packages though.
nx repo is much more advanced i guess , but harder , so does the bazzle . they are enterprise grade , while turbo is good for small agencies , and self sufficient apps
I understand what you are saying - But I don't see the downside of having the code split into packages? looking at the folder structure - Everything seems more organized? Even if I am not building a mobile app - The folder structure looks great - and just having them split into folders seems like the correct thing to do? Am I missing something?
You will spend less time (means money) placing API directly in the nextjs project. I guess this is what Josh meant
Almost all apps need the same reusable boilerplate functionality like Auth, Analytics, Payments, etc... so it makes sense to extract that logic into packages, then easily reuse it when bootstrapping a new project under the apps folder.
As a C student, wouldn't just be easy to do it like we've always done and use a service like strapi build all your api, and connect it to the front-end decoupling the frontend and backend? What is different about that concept?
Amazing Alter ❤. But doesn't it more scale your chances to be found via a mobile app right from the start rather than building only a webapp?
Indeed but need to replace some with OS Alternative.
Out of interest if you would hope to get to mobile down the line, would it not be best to start from a position where that could be possible?
It's all hypothetical and down to the project of course but what is the bigger burden; the initial abstraction setup or having to abstract an existing project.
NextJS is Enterprise, Nike and My Job and many more use it
That doesn't make it enterprise. Its easy to say "X Brand" uses a framework when it could just be for marketing or docs sites vs. anything critical to core product.
Hey, I've been curious how would you refactor from just Web to accommodate mobile. Do u start a new repository or do u start moving folders around
fyi web is the landing page and app is the actual web application, not a mobile app
I thought you would give us a complete walk-through of this repo and explain the setup etc... I actually requested the creator of this repo from the same tweet he did agree to do a video but you know.... these guys.. I think they're already planning to add more features to it
Honestly its pretty minimal and nicely laid out skeleton of a project. Simply running down the list of items in the apps and packages directories should tell you a LOT. If there's any piece of the puzzle that doesn't make sense for you click into it and search for what imports it. Kudos to them for an intuitive project layout and clear descriptive concise names. A thing that's missing that I would require if managing a project that would also help you answer a lot of questions is for every app + package to have a README that at a minimum has a topline explaining how it fits in and identifies any special dependencies and third-party services or API's and what's required to get rolling with them both for dev and production (+ direct links to relevant docs + URLs). I never assume the dev is a TS ecosystem fanatic nor somehow knows what some trademark brand name service actually does. This helps onboard devs way faster among other benefits.
@furycorp I just started learning monorepo and turborepo a couple of weeks ago. So yeah wanted to have more in-depth details as you mentioned a README would be great. For instance I wanted to know the reasoning behind having the UI as a separate complete app instead of having it as a package.
@@dreamsachiever212 generally in a monorepo the popular convention is that "apps" are things that are deployable whereas "packages" are libraries that export code for import by other apps and/or packages in the workspace (i.e. like all the public packages on npm).
Big Picture: the apps and packages directories are only a popular convention: the directory names "apps" and "packages" are actually completely arbitrary. With pnpm workspaces you can organize your workspace however you see fit. pnpm reads `pnpm-workspace.yaml` for the list of directories to scan for packages to consider as part of the workspace. For example some people like to define a separate "configs" top-level directory for packages that export shared config files so they're not lumped with other "packages". As another example some people prefer "libs" directory name to "packages".
Yeah I'll record something in the next week or so. I'll be adding more features, but very carefully. The line between useful and overcomplicated is a fine one.
It's useful for learning purposes but not for solopreneurs, as you've said, this starterkit is 'ENTERPRISE' for companies already stablished.
there's very little enterprise about this. its definitely solopreneur level for a real thing in production.
Keep in mind that you have to use vercel if you decide to use this template
You can likely deploy it elsewhere (Netlify, Custom VPS, etc.) - I just haven't written guides on it yet.
@@haydenbleasel1vercel bs is deeply cooked in this project
so, any actual good monorepo startekit you can recommend for nextjs with NextAuth, Prisma ORM, Stripe you can recommend? =)
Can you please make a tutorial of building a framework similar to Convex one?
Hi Josh, was wondering what headphones you are using?
How is the google analytics implementation has it a cookie consent banner that is working?
"enterprise-grade" - Uses Prisma xD lol
Can you make a turbo app tutorial for both for web and mobile app for same e-commerce platform?
Microservices ? How … often theres a confusion on serverless and microservices. While they can be used together usually microservices have well#defined boundaries that encapsulate end to end business logic , each service is independently deployable (for which part you often see it ship with its own database) essentially a black-box. In the repo we have a lamda - cool but lets not label it “microservice”
make more videos like this
Enterprise software with Prisma? Hell nah, in my own project compared it to a medium sized query, it was 2x slower than raw sql. Kysely has the performance and typings and you can use prisma schema
This is not micro services, basically this one monolith service
Hi Josh, can you build yelp clone
Why and who thinks that for building production grade software needs shorts no,stop using clerk,etc. they are not what professional uses
most of the enterprise companys uses angular, nextjs is just for twitter hype dev
Which browser do you use?
That's Arc browser
Could be better if they use jwt or oauth2 instead of clerk like laravel
11 min ago is crazy
Why don’t we just use a cappacitator for the mobile
what is that?
@ i only search about it i have no experience but for what i understand it is something that you can wrap your next js app and it will also compile to mobile but like i said i have 0 ideia how it works since i haven’t reach that phase yet
Nextjs for enterprise lol
Why not?
What the hell microservices your talking about bro?
Sorry but that repo it's trash
Next js can never be an Entreprise level development framework ....
🤦🏾♂
Yeah I like Next.js, but it lacks bunch of things on backend side to make it even production ready (let alone enterprise ready) for backend work. For frontend work it's pretty good, but backend not so much. It just lacks so many basic features to be a full app building framework.
This boilerplate is unfortunately just another boilerplate that combines bunch of SaaS software together. At least it's free and people behind it are not trying to charge few hundred dollars like I've seen some others do.
What is nextjs missing? For the backend. @@rand0mtv660
@@rand0mtv660next.js is not production ready that is why Varcel aqure Tourborepo
Why prisma its pathetic. I would never use that for an enterprise application.
nobody cares
What’s wrong with prisma?
@@ramongodas You costumer will care when everything is slow af. Your wallet will also care when you are spending 10x more due to overfetching, multiple roundtrips and what not.
@@dvillegaspro it encourages devs to do things that actual DBA's wouldn't do and break postgres conventions in favour of TypeScript conventions. Definitely not good for any actual business app where data is the lifeblood of the business. Imagine blocking an army of data science + analytics, business analyst, DBA, and IT people (and their preferred tooling) because some JS/TS dev picked something that suits only them. You're also always missing tons of postgres features that are central to real-world enterprise apps but Prisma doesn't support. Prisma, Drizzle, and others ALL have issues with their DSL's for defining schemas: they mimic SQL but subtract features. For example you can't actually follow best practices as documented by postgres with either because the schema definition language doesn't support those features. In fact these things will auto-generate schemas that have items on the "DONT DO THIS" list from the official postgres docs.