Tech decision: Which queue service?
Right now I'm using NextJS with tRPC and want to send an email if someone replies to a post. But I don't want to block the tRPC query with sending an email.
I thought a queue would be right thing to do. But which queue service would you think is the best for my setup?
19 Replies
How much traffic do you have? How many users? Is this maybe just a pre-mature optimization? You could just send the email within the same function that handles the reply and don't bother with a queue until it actually becomes a noticable problem
If you however want to, you have azure service bus/storage queue, cloudflare queues or something like uhhh BullMQ
or AWS SQS, but agree on not using queues until it's a noticeable bottleneck to send immediately.
@Clearlyunwell @chip The problem is that I have the query and on finish of the query the page gets revalidated and the user sees his post/comment if I would add the email to the query the user would see his post way later.
I see. So you want to fire and forget the email so you can get back to the user quicker. In this case queues would solve the problem. So would a database entry with the email data. Any mechanism to offload the actual sending of the email. But you’re asking which queuing service is recommended - I think that’s been answered 🙂
Sorry for the unrelated question. I’m just curious about how you’re triggering the revalidation from tRPC? I couldn’t figure out a smooth way to trigger it from a
useMutation@FleetAdmiralJakob 🗕 🗗 🗙 There is also https://www.inngest.com/. Perhaps the simplest if deploying the app to Vercel.
Inngest - Build reliable products - Durable workflow engine
Easily develop serverless workflows in your current codebase, without any new infrastructure. Using Inngest, your entire team can ship reliable products.
I triggered it inside a server action
I will try this one out, since it seems very easy to use
Yeah and it's free for up to 50.000 jobs/month.
Can only recommend Inngest
Oh ok, are you able to get tRPC context (auth) in the server action too? Because I guess it's available in the middleware anyway
tRPC Middleware works as expected
Repo: https://github.com/FleetAdmiralJakob/postparrot
https://github.com/t3dotgg/server-actions-trpc-examples
GitHub
GitHub - FleetAdmiralJakob/postparrot: A nice little twitter clone
A nice little twitter clone. Contribute to FleetAdmiralJakob/postparrot development by creating an account on GitHub.
GitHub
GitHub - t3dotgg/server-actions-trpc-examples
Contribute to t3dotgg/server-actions-trpc-examples development by creating an account on GitHub.
@Mocha
Thanks a lot! Much simpler than I expected
@peterp @sandulat Hi, I wanted to start building this email feature but now I'm wondering which is better suited for my usecase the background jobs or the queues. Do you have any insights or tips?
If you want to send an email then just use Resend
@peterp
dawg?
Can’t you just move the email logic to an API endpoint that you call without awaiting?
This way the request is triggered, and since the API endpoint is the handler, even if you don’t await the result and just
void sendEmail() it will still continue handling the request