I want to create a web application and I’m considering separating it into two parts. The first part would be an API that handles data and returns responses in JSON format. The second part would be the user interface that talks to this API to get the data it needs.
My plan is to make the frontend work even when JavaScript is disabled. Instead of using AJAX calls, I would use server-side HTTP requests to communicate with the API. This means I would have two independent applications running.
I’m wondering if this architecture is worth pursuing or if it might cause more problems than it solves. What are your thoughts on this approach?
what’s behind the no-javascript requirement? is it for accessibility, specific users, or compliance? i’m curious cause it’s driving your whole archtecture. how do you handle form validation and user feedback - just full page reloads for everything?
you’re overengineering this. why build two separate apps when one would work fine? the no-javascript approach feels outdated, and you’re creating unnecessary network calls. build something simple first and save yourself the headache.
This setup works but adds a lot of complexity that’s probably overkill for most projects. I built something similar for a client portal that needed both web and mobile access. The separation helped when we added the mobile app later since the API was already there. But you’re basically maintaining two codebases, dealing with auth across services, and handling network lag between your frontend and API. Plus those server-side HTTP calls to your own API add an extra hop you wouldn’t need with direct database calls. I’d start with a standard monolithic approach and pull out the API later when you actually need multiple clients. The refactoring isn’t too bad, and you’ll know exactly what you need to separate by then.