Re:You probably don't need a single-page app
by pjc50 on Sunday February 17, 2019 @12:22PM
(#19185541)
IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.
Re:You probably don't need a single-page app
by a_wild_dandan on Sunday February 17, 2019 @02:44PM
(#19186394)
Apologies if I misunderstood you, but isn't all of that criteria met by a Node/GraphQL/React app?
1. One language - JavaScript
2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing)
3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations
One language, one repo, easy & consistent API production/consumption, no?
Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.
But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.
With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.