akshat
akshat•2w ago

new product for fintech company

Hey guys, I'm building out a new product for our fintech company and have been experimenting with a traditional stack vs convex. Love some of the features and ideologies around convex. I was against using it until I learned internals of how queries and mutations are ran under the hood. Here's a couple questions I still have around convex for my specific use case. - The web app is going to be used by an older audience, and they might have legacy browsers. I haven't looked through the convex client side sdk, but do you guys think it's going to be well supported across browsers ( android, ios, web, legacy etc ). I don't think we have to go as far as to support Internet Explorer, but I'm guessing just a level above that. - The initial version of the app is going to be mostly forms ( kind of like typeform ). User filling out information and going through different screens. In a more traditional stack I might make post requests to the backend after every screen and then do a redirect to the next page. Is there a different mental model while using convex around building screen flow? For eg. In a traditional stack after each "step/screen" I might send a post request to the backend to sync the data to the backend, and redirect the user to the next page from there. But in convex, it's possible to talk directly to convex to sync data from the fe, however I'd have to handle the routing logic from the frontend then. Any pointers / recommendations would be helpful. 🙂
No description
3 Replies
Wayne
Wayne•5d ago
Hi @akshat saw your tweet. Some thoughts below.
Wayne
Wayne•5d ago
Browser Support Question Convex doesn't have an official browser support policy yet, but we target modern browsers. I don't have an official answer on whether Internet Explorer isn't supported, but you should be fine with anything above that level. For Android, iOS, and web browsers from the last few years, you're good to go. Reference: Production: Status and Guarantees Form Flow Architecture with Convex Traditional Approach:
Frontend sends a POST to the backend, which handles routing and redirects. Convex Approach:
Frontend calls a mutation to save data after each form step, and the frontend itself manages routing (e.g., with React Router or Next.js router). Use queries to reload saved data when users navigate back. This results in a cleaner separation: Convex handles data persistence and real-time updates, while the frontend manages user flow and screen transitions. Reference: Building an Application Portal on Convex. Implementation Pattern 1. Save form data after each step using mutations. 2. Handle routing in your frontend. 3. Use queries to reload saved data as needed. Best Practices - Use argument validators for all form mutation functions. - Use indexes for efficient lookups instead of filtering queries. - Update form data with .patch rather than replacing entire documents. - Keep mutations focused—one per form step is effective. Use Convex’s useMutation and useQuery hooks to keep form data in sync after each step. Convex manages real-time updates and consistency, so you don’t need manual polling or cache management. This approach simplifies backend communication and ensures your UI stays in sync with the database. Reference: Why We're Loving Convex.
Status and Guarantees | Convex Developer Hub
Learn about Convex's production guarantees, availability targets, data durability, security features, and upcoming platform enhancements.
Building an Application Portal on Convex
Working with Convex has made our development workflow so much more streamlined—we no longer have to worry about the complexities of traditional fronte...
akshat
akshatOP•5d ago
This is helpful to get the recommended way of doing this. Although it's not ideal to have to have to manage routing on frontend ( especially if we want to do programmatic routing based on user answers ). I'm guessing it'll be best to use convex as a traditional db and route requests through nextjs / server in order to have control over that, especially because we might not need the realtime sync for that particular use case. I think I can manage this. What are your thoughts on exposing the convex endpoints from the frontend, since there is no login / authorization on the application. I'm planning on either using anonymous users or no users at all. How can we protect the endpoint against ddos or malicious actors spamming it. Traditionally I might put the api endpoint behind cors + cloudflare ( turnstile ) or rely on vercel bot protection. Is there recommendations on how to secure convex endpoint against malicious activity? My goal is to get a comprehensive understanding of convex, baas is a hard thing to build. This is the closest I've seen anyone get.

Did you find this page helpful?