Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
why was your controller/response waiting for the confirmation email to be sent to begin with?
wrap the email-logic in a new thread and start it, so the response is sent and the only overhead is the thread-creation-time
the code inside the thread can update the DB whether it was successfully sent/delivered/error
why use a queue unless you're expecting thousands of users where ur worried that ur SMTP/email-handler will start hitting the rate limit? -
@b2plane ah, even in an async method, the next instruction (ie ur response return) will still wait for its completion if you 'await' it
https://javatpoint.com/thread-conce... use threads, but make sure the state changes are thread-safe
Just cut down registration from 5s api response (because its sending email confirmation) into 70ms using rabbitmq (emails are now delegated in rabbit queue and sent whenever the queue takes place)
But still around 70ms to register which is great and fast (because it also generates jwt token and returns the whole user object + jwt) so its difficult to keep this at 7-9ms response time
Is this normal and is it fine to leave it at 70 or can this be optimized (or should it be)?
rant