I’m coming from mobile development and I’m pretty new to web development stuff. I’ve been building this side project with Spring Boot and recently switched from a local PostgreSQL setup to using Supabase for my database.
Now I’m wondering if I’m overcomplicating things. Should I just skip the whole Spring Boot API layer and have my frontend talk directly to Supabase? It seems like Supabase can handle most of the database operations I need.
I spent weeks building REST endpoints for basic create, read, update, and delete operations. Maybe I didn’t need to do all that work if Supabase already provides those features out of the box?
Having gone through a similar transition myself, I’d suggest keeping your Spring Boot backend despite the apparent redundancy. While Supabase does eliminate much boilerplate code, a custom API layer becomes invaluable as your application grows. You’ll eventually need complex business logic, data validation beyond basic constraints, integration with third-party services, or custom authentication flows that Supabase alone cannot handle. The Spring Boot layer also provides better control over caching strategies and allows you to implement domain-specific optimizations. Consider your current setup as future-proofing rather than overengineering. That said, for simple CRUD applications or prototypes, direct frontend-to-Supabase communication works perfectly fine and significantly reduces development overhead.
honestly depends on your apps complexity tbh. if its just basic crud stuff then yeah go direct to supabase and save yourself the headache. but if youre gonna need custom business rules or api integrations later then keeping spring boot might be worth it. i’d probably go direct for now and refactor later if needed
what kind of business logic are you plannig to implement down the road? i’m curious about your use case because that really drives the decision imo. also have you tried supabase’s row level security yet? thats usualy where people hit limitations when going direct from frontend