Using create-t3-app for a websocket heavy app / proxying api requests
So at work we're looking to rebuild our frontend (a stock trading application) from scratch, it's currently made with angularjs (I know). So I was looking into t3-stack/next.js as a possible new stack.
However there's a few caveats, my team is pretty adamant on using RTK Query because of the logging that RTK offers. Also most of our data comes from a 3rd party websocket, and I was wondering if it is even worth using next.js if most of your data comes from a websocket.
Also, all of this is moot because I can't seem to get proxying to work, I need to proxy our api calls because of cors issues when running in local dev. I have both tried the http-proxy-middleware and the rewrites option in next.utils.js, and it doesn't seem to be triggering, all my axios calls are still going out to 'localhost:3000/api/whatever'. If anyone had a suggestion or example of proxying in next.js it would be appreciated
4 Replies
This is a pretty fun one
Thought dump:
- Next is usually worth it if you have any data you'd like to use to determine what experience to start with. Obnoxious things like auth state and font management are much easier with a little server magic
-
next.config.js not next.utils.js, I am 100% positive rewrites work as I use them daily
- RTK Query is far from my favorite, but if the team is hell-bent on specific features like logging then...sure? I think the dev tools for React Query are pretty great and you can write a custom logger in your client: https://tanstack.com/query/v4/docs/react/guides/custom-loggerCustom Logger | TanStack Query Docs
If you want to change how information is logged by TanStack Query, you can set a custom logger when creating a QueryClient.
`tsx
- "most of your data is from a websocket" the majority of my data is from websockets, and managing the chaotic state machines they represent is the majority of the hard work I do on web apps, but these tools still make the other parts way less complex
glhf
Wow, a response from the man himself, awesome!
- The proxy issue has been fixed, turns out my team lead added something to the api that only allows request from the :9000 port, he neglected to tell me and I was running on port :3000. Wasted a good bit of time on that one.
- I did see the custom logger option for tanstack, but as it said it would be deprecated it seemed less interesting.
- So in our case, you subscribe to tickers, put in orders etc through the one websocket. So for instance a ticker is something that would need to be in the global state. Is that something you would handle with tanstack query, or more something like Zustand. As you called it a state machine I seem to remember from one of your videos that you prefer Zustand for stuff like that.