I'm inside of our root handler so at the very top we're going to import that publisher that we just
created and make sure that we publish the payment Create Event after saving our newly created payment.
So the very top I will import my publisher
and I'll import that from up one directory events publishers name integrated publisher
then back down right after our payment got saved.
I'm gonna create a new instance of the payment created a publisher.
Don't forget we do have to provide a Nats client to this thing and that means we need to also import
our Nats wrapper at the top of the file as well.
So at the very top I will also import my Nats wrapper from up one directory Nats wrapper
then right after we create the new publisher I'll stick in the Nats wrapper client.
We have to call publish on there and to publish we have to provide some data for the event itself.
So again if we forget what we have to provide we can always mouse over the air will be sold.
We have to be get to provide the idea of the payment to what's created the order I.D. and the stripe
idea as well.
No idea.
We will throw in payment that 80 where the order I.D. we could use the order I.D. that was defined backup
here but as best practice we really like to take information directly off the record that we just saved
instead because who knows we might be making some adjustment to the order I.D. we might be changing
in some fashion team with a stripe I.D..
Obviously we're not doing that in this case but it's usually just best practice to take information
off the record we just saved because we don't know if there's something kind of massaging that information
before it actually gets stored inside the database.
So for the order I.D. or reference payment what order I.D. and then for the stripe by the same thing
here payment dots stripe I.D.
Now again we might choose to await this if we await this then we're going to make sure that we await
to publish the event before we send a response back.
Alternately we could remove the awaits and just say hey let's just send back a response as soon as possible
and we're not going to worry about handling or waiting for the event to be published.
So going to save it like this and now the very last thing that we might want to do is return some more
meaningful data than just a success.
True right here.
So maybe instead we should return let's say maybe the entire payment object or maybe just the payment
objects I.D..
Really in this case just about any return value is totally fine because we're not really going to make
use of this information at any point in time inside of our ReACT application.
So how about right now we'll just return the idea of the payment that was created
if you want to.
You could definitely write out a test around this and make sure that the idea that is being sent back
is the same as the payment that was actually saved to the database.
Totally up to you but I'm not gonna worry about it too much.
All right well that's pretty much it.
That is our payment service or at least the payment route handler let's take a pause right here as usual.
Continue in just a moment.