Hey did everyone if they share and welcome to another new section.
I know this course is a bit longer one but I really wanted to cover pro back end of the part like it
means to say as pro I wanted to go in depth and that's exactly what we'll be doing.
Now this section, you can go ahead and watch it in 1.5 X or maybe more.
In this section.
We're going to cover a lot of theory work not too much, but a bit of theory that is required for this
course itself as well as we're going to do a small mini project by integrating a razor pane.
Now, this is one thing which actually sometimes amuses me a little bit that people say, Hey, I know
how to implement Braintree, but I don't know how to implement Stripe.
Some people say, I know how to implement Braintree and Stripe, but I cannot implement Razorpay or
Paytm or something else.
Now, my point is that if you really have thoughtfully understood the concept of implementing a payment
gateway, then implementing the stripe or Razorpay or Paytm or pay you money or any other is almost
kind of exactly same.
But the thing is, most of the time a lot of people, not you, but a lot of people actually just write
code along with the instructor.
They don't give it a thought for a moment that, okay, this is how I should understand the things and
that is the most important aspect of it.
So in this particular section, we're going to discuss a bit theory in the initial phase, and then
we're going to create a very minimum viable project which will include how to get payment with the RAZORPAY
done.
Surely we can make it complicated.
We are not going to do it right now.
We will be keeping it as a separate project itself and we'll be working on that.
So this is what it is and make sure you go ahead and create an account on the Razorpay because that's
what we'll be using.
You don't need to go into the actual mode, production mode.
You can be still in the test mode.
I have just created an account here for the testing purposes.
I use that just for API keys, so go ahead and create that.
We will be reading together the documentation of Razorpay.
It's exactly the same as Stripe.
Very familiar, actually, very similar to Stripe itself.
So shouldn't be a big deal at all.
So that's basic.
You have to do.
And let's go ahead and talk about the back end of LPR.
So we are about to move into the phase where we are going to build an entire E commerce application
and this will give you more confidence of how to develop a proper project and how to add functionality
over the time into it, or at least how to design that.
So we're going to go ahead and we are going to be implementing everything onto that one.
So let me go ahead up here and let's go ahead and simply combine that all we got for this one.
So so far, whatever the knowledge we have gained so far, we will be going ahead and we'll be using
that now.
Definitely we'll be add we'll be adding a little bit more to this one.
So first, a concept that we are going to discuss is a file structure.
Now, there are there is a lot of debate around how you should be doing it, how you should not be doing
it.
Some people like to divide it so much in depth.
Some people just like to divide it.
Basics, stuff again.
Which one is good?
Which one is right?
There is no right or wrong here.
As long as you are able to properly see where the things are.
That's all it matters.
There is no written definition that you need to follow.
Again, it's all personal preference, but this is the basic reference that I personally use in all
of the production grade application, and mostly you're going to see almost exactly the same.
So let's go ahead and discuss what each of these folder comes and contains into that.
So obviously this is the route that means this is the basic folder, the empty one, which you're going
to push it on to the GitHub or somewhere to deploy it.
Now the very first folder that I usually like to create is config.
Now this config includes a lot of configuration file and I like to keep my database file into this one
as well.
Do I need to?
Not really.
Some people create a separate folder, which is just the database, and in that we have a database connection
file.
You put it into config or the database folder totally on you.
You can go ahead and change that.
I usually prefer to that.
I have even seen that some people actually prefer to put this dot E and V file into the config because
they have the argument that configuration is inside the environment variable that should also go there.
I personally don't do that, but you'll see a lot of people does that no harm in that.
Also now controllers now so far we have seen the method that we have been writing, which is request,
response and all that method.
This needs to go into the controller.
Now, I personally believe also that this is always a good way to separate out all of your controller.
Maybe later on you want to go into serverless or something.
So separating your controller is the most important thing that everybody should be doing it.
If you are not going to do it, you are going to not make your application scalable and workable by
a lot of other people.
So having a separate controller always makes sense the middle where you will be needing a lot of middleware
and we are going to talk about that in the future.
Videos and the theory itself, middleware is like something a specialized middleware which is handling
your errors, your custom errors, maybe a middleware which is identifying whether you are logged in
or not.
A middleware which is identifying what role you are having admin role, manager role or a simple user
role.
So how you are going to identify these things, they actually goes into the middleware.
They.
Don't do much of the stuff.
They actually just return you the next based on what you really want to do.
So there is not too much of the information in these files.
Next step is the models.
So this is obviously a production grade application.
So we need to go ahead and put some database information here as well.
Model is like a basic bare minimum structure that this is how the things are going to look like.
For example, you are signing up the user.
So what information you are going to be taking from the user, maybe their first name, last name,
their address, email, information, password.
So all of this needs to go inside a model itself that is a structure and we are going to design a couple
of models together.
So that will help you to understand it a little bit more.
Then comes up is the route.
Now a lot of people don't like to break their roots like this.
I personally love to break it like that.
It helps me to kind of scale application easily.
For example, if I am having an application which is an e-commerce store or maybe a hotel booking that
is a single product, there are a single hotel that I'm putting out.
So all the routes related to that product or that hotel goes into a single file.
So that is absolute amazing way of architecture in your application.
So whether I want to add a product, delete a product, edit a product, whatever I want to do with
the product, I can do it in just one file and it keeps things at a central place.
That's why I like to keep that.
Next come up is the seeds.
Now, this is a little bit of a new folder to you, but it usually exists there.
Now the idea behind the seed is sometime maybe there is a guy who is testing your application or the
front end guy who is having a less idea how the data will come up.
So in the seed file, we actually get a simple two things.
The first is connection to the database, and second, some of the dummy data.
So as soon as you are going to run the seed file, it will connect to the database and then we'll throw
up some information in the database.
It includes some dummy users that log in and password that are pre known to the entirety of your team.
Some information about product.
So every single model that you have created in the database, it is going to fill a few information
in that.
So that is easier for the tester or maybe the front end guy to actually see some data coming in because
the application is new, it's not being deployed.
So we need some kind of information there.
Now it's up to you that how you're going to provide the seed information, maybe through some packages
or library like Faker, or maybe you are going to manually enter that totally up to you.
We are not going to discuss that too much in this course.
Then comes up is the utils.
Now these are utilities which are really, really basic, but you want to still keep them as separate
utilities.
For example, sending email that could be one, sending an OTP via a mobile phone, that could be one.
The reason for separating them is maybe you are having a basic information of how to send email that
always remains same.
And maybe later on you want to use send in blue, maybe eight blue email services.
So there are a lot of services available and you want to configure them.
But how you send email basically always remains the same.
Just the configuration changes out.
So that's why you keep all the utilities totally, entirely separate.
Maybe a function which you are using probably ten different times in your application.
It's a best idea to push that into the utilities and everybody then can use it.
Then of course our all time favorite get ignored file.
So all the files that you don't want to push to the source code onto the GitHub or any repository that
all goes into the git ignore kind of basics for the get dirty.
And B we had a long discussion about this simple package dirty and we can give you this file, you can
create this one and all the information, secret information like your keys, secret keys and all of
that information resides here.
And at the time of deployment, we go ahead and just place it there.
Whatever the service you are using, Heroku, Digital Ocean doesn't matter.
All of them gives you the information to upload that.
And yes, you have to manually write all these values.
There is no automation happening there and after that comes up is your root file which can be JS indexed
or JS server or g is something, logs, whatever it can be.
This is the basic entry point of IT application.
I usually prefer to keep it as a keep it as indexed or JS and I use the same functionality that we saw
in one of the earlier section that I like to keep indexes separate and also my G is there which actually
exports the app in the index or GSI, import that app and run the application.
So kind of a basic one.
So again, don't freak out.
Break your application.
It's a good habit, but don't break it too much that you just get lost into it.
Make sure it is all kind of makes sense when you are breaking your application.
So that's how you keep your folder structure.
This is basic.
Again, this is not a compulsion, but this is what you are going to see in majority of the application.
So a bit of a theory told you watch it in 1.5 and let's catch up in the next video and discuss a bit
of a tiny subject in the next one.