3 ms·

It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the commun

by abraae 8y ago

It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." 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.

rhapsodic 8y ago
>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. YAGNI
pjc50 8y ago
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.
- a_wild_dandan 8y ago
  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?

by abraae 8y ago

rhapsodic 8y ago

>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. YAGNI

pjc50 8y ago

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.

a_wild_dandan 8y ago
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?