It can easily be done with joi package. I will create an extra episode for this. But at end of course. For now we just turn out focus on authentication
I come from another language/framework. Some solutions you apply seem strange to me: 1. It seems hard to believe that such a basic feature as .env file support requires so much setup in NestJS. Is this the general way to do it, or is this applicable for your specific use case in your specific project? What is the basis that is generally enough for production level NestJS applications? 2. Why don't you use ConfigService? Your approach without ConfigService leads to manual type conversion, which does not seem to be a good practice. 3. Why would you disable TypeORM synchronize in prod, but enable it in dev? Won't this hide incorrect migrations and lead to bugs in stage/prod?
1- .env Setup in NestJS: Great observation! While .env support can feel more straightforward in some frameworks, NestJS intentionally separates concerns to align with its modular architecture. Using the @nestjs/config package for .env management is considered the standard way in NestJS, providing flexibility and scalability for larger applications. While it may seem like more setup initially, this approach ensures you can easily manage configurations across modules, which is particularly helpful for production-grade applications.
2- ConfigService Usage: You’re absolutely right about the benefits of ConfigService-it abstracts away manual parsing and type conversion, making configuration handling cleaner and more robust. In this project, I chose a more direct approach to show how the system works at a lower level, but I agree that using ConfigService is a better practice for production. I'll make a note to cover this in future videos to highlight the advantages!
3- TypeORM Synchronize: Enabling synchronize in development is helpful because it simplifies schema updates during active development. However, in production, it’s best to disable this and rely on proper migrations to ensure controlled and predictable database changes. You're correct that failing to test migrations thoroughly in a staging environment can lead to bugs in production. Best practice is to rigorously test migrations in a staging environment before deployment.
By the way, if you enjoy learning and want to dive deeper into computer science topics made simple, I run another channel where I summarize key concepts from CS books. I would be very glad if you subscribe to my new channel: ua-cam.com/channels/ZYhXrFwhFUOXuSQNgfk-Sw.html
A dense, yet fruitful video
didn't know .env and config can do all fo that
Thank You Vahid
Thanks for watching, I'm glad you found it helpful!
The Best course of Nest js 💯 thank you 🔥
Thank you so much for your support ❤️🙏
very nice bro, thnaks(دمت گرم)❤❤❤❤❤❤
Mamnoon ❤️
Nice Video!!
Thank you! I’m glad you liked it. More videos are coming soon, so stay tuned! 👍😊
great one
My pleasure! 😊
which theme are you using?
It's bearded theme
after adding env variables. our seed functionality is broken
Hi, what is the error?
What about type safe env (would love to see autocompletion intellisense to my env)
It can easily be done with joi package. I will create an extra episode for this. But at end of course. For now we just turn out focus on authentication
@@SakuraDev can it be done with Zod?
@@robertz7329 I should test it. It would be great if we could do it with zod
I come from another language/framework. Some solutions you apply seem strange to me:
1. It seems hard to believe that such a basic feature as .env file support requires so much setup in NestJS. Is this the general way to do it, or is this applicable for your specific use case in your specific project? What is the basis that is generally enough for production level NestJS applications?
2. Why don't you use ConfigService? Your approach without ConfigService leads to manual type conversion, which does not seem to be a good practice.
3. Why would you disable TypeORM synchronize in prod, but enable it in dev? Won't this hide incorrect migrations and lead to bugs in stage/prod?
Thank you for your detailed questions! 😊 Let me address each point:
1- .env Setup in NestJS:
Great observation! While .env support can feel more straightforward in some frameworks, NestJS intentionally separates concerns to align with its modular architecture. Using the @nestjs/config package for .env management is considered the standard way in NestJS, providing flexibility and scalability for larger applications. While it may seem like more setup initially, this approach ensures you can easily manage configurations across modules, which is particularly helpful for production-grade applications.
2- ConfigService Usage:
You’re absolutely right about the benefits of ConfigService-it abstracts away manual parsing and type conversion, making configuration handling cleaner and more robust. In this project, I chose a more direct approach to show how the system works at a lower level, but I agree that using ConfigService is a better practice for production. I'll make a note to cover this in future videos to highlight the advantages!
3- TypeORM Synchronize:
Enabling synchronize in development is helpful because it simplifies schema updates during active development. However, in production, it’s best to disable this and rely on proper migrations to ensure controlled and predictable database changes. You're correct that failing to test migrations thoroughly in a staging environment can lead to bugs in production. Best practice is to rigorously test migrations in a staging environment before deployment.
By the way, if you enjoy learning and want to dive deeper into computer science topics made simple, I run another channel where I summarize key concepts from CS books. I would be very glad if you subscribe to my new channel: ua-cam.com/channels/ZYhXrFwhFUOXuSQNgfk-Sw.html
Why this.configService.get("dbconfig.env.type) is not type safe and there is not autocompletion intellisense? It is just a string.
Well, the config service does not have type safety out of the box. We need to use third party packages to add type safety
@@SakuraDev I will keep this in mind. Thank you :)
@@FejkMarcin1212 🙏🙏👋