Using ConvexHttpClient in a Next (App router) API route
So i'm trying to process a web hook from MUX, that comes in on a endpoint i setup in my next API routes, but im getting this console warning about unable to resolve 'encoding' from fetch/lib . Anyone knows if this is worth thinking about?
The warning happens when i post a request to the api route, currently im on the dev server and sending a test request from thunder api client for vscode.
The mutation goes through, so unsure if this is even a convex related question - might just be me not knowing how to do route handlers 👀
Don't know if it potentially could be the way i export the client from my backend package, because im using a monorepo:
5 Replies
@ballingt will have a better idea what’s going on with our fetch, but I’d recommend using Convex HTTP action instead of Next API route for handling the webhook, if you haven’t considered that yet:
https://docs.convex.dev/functions/http-actions
This way you can call mutations directly and avoid an additional roundtrip between hosting server and your convex backend.
HTTP Actions | Convex Developer Hub
HTTP actions allow you to build an HTTP API right in Convex!
Ohh I haven't considered that, didn't know about HTTP Actions. I will take at look at that right now. Thanks Michael
Update:
Looks very cool, so i'm assuming HTTP Actions allow me to then point the webhooks from MUX to an endpoint like:
https://<your deployment name>.convex.site/mux-endpoint
I mean, this is so neat. If im understanding this correctly, i def have some other things i can move to this approach
You’ve got it right!
Re the encoding issue, we've see it before: it's a warning you can ignore. This is a node-fetch / Next.js interaction. https://discord.com/channels/1019350475847499849/1154821099314495518/1154821099314495518
There are some links to ways to solve it linked in that thread (I think it's just adding "encoding" as a dependency) but it's not necessary.
Ahh gotcha. Thanks for clearing that up Tom