3 ms·

> if you have a person's profile picture, and you want to round it, should that be a property on the JSON structure? You can decide what to leave to frontend o

> if you have a person's profile picture, and you want to round it, should that be a property on the JSON structure? You can decide what to leave to frontend on a case-by-case basis. I would say unless people can choose if a picture is rounded and it's saved in database, this is valid to leave up to frontend. > Maybe its text weight: How generic should it be? Very-generic: "title". Kinda-generic: "heavy". Or literally just CSS. If text has sections that are formatted differently, backend could provide content for those sections separately. Styles are up to frontend. > Does the contract allow for lee-way in how its responses are interpreted? How much lee-way? Structure and content on the backend, presentation on the front-end. > designers want it to become a bottom bar. No problem, except, uh, the API says it should be a sidebar Call it something a little more encompassing, like "secondaryNavBar". > you just doubled the work of a visual redesign. If the data model were generic, your backend team may not have even had to have been consulted. There's a fair criticism in here, however the work is not doubled. 1. You can make some redesigns without changing field names, then slowly align JSON keys. The damage from this concession is contained in each page individually. That said, updating the JSON keys as you go should not be much more work than the redesign itself. 2. Should we be optimizing for rare redesign when instead we could optimize for ongoing maintenance? 3. How likely is it that redesign doesn't need anything new from backend anyway? 4. How likely is it that redesign won't introduce new N+1 problems? > Do you have something like { "form": [ { "formTextField": { "id": "firstName" } } ... { "formSubmitButton": { "endpoint": "/createUser", "verb": "POST", "arguments": { "id": "firstName" } ... } } ] } To render the form, you don't need to send the form to the frontend. Frontend could render the form by itself. You just just send it any pre-filled values. Form's action/method are also okay to include. > What if one page that calls /createUser needs to display the error in a snackbar, but another page needs to display it in-line with the button? Do you just... not do that? Just throw every error into a snackbar? Just because you mostly render full pages, doesn't mean it's illegal to have endpoints that give you snippets of data in response. Your createUser endpoint can respond with just a list of errors. It wouldn't be bad for mutating endpoints to do that, the benefits of this approach still remain. I've addressed the points you've made, but seems as though they allowed you to build up a strawman, and the rest of the comment is knocking down that strawman. That's not what's being proposed here. It's okay, maybe you are arguing against specifically what you have at your work. I could help adjust your framing if you'd like, let me know.

015a 5y ago
That's reasonable criticism of my criticism. I would defend myself by saying that it feels like the opposite is also true. I built up a strawman and struck it down, but the recommendations in the original blog post, and here, are defined in extremely abstract terms, then defended with "you can do it however you want, there's no rules" such that every team who implements it will do it differently, and inevitably most will spend years landing on ten bad ways of doing it, never reaching the nirvana of what was promised in the abstraction. I do like the idea; but in a limited capacity, and I'd caution teams from planning an entire application around it. I'd stick to fragments of pages which are highly data-driven, and be more cautious around layout and structure.
- hakunin 5y ago
  In case anyone else feels that this article leaves enough wiggle room to accidentally end up with something like 015a described, here are the 3 rules I implied in answering the above post: 1. All structure and content goes to backend. 2. Find good names for size-adaptive sections. 3. Responses to write requests can be anything. I think 1 and 3 are covered in the article, but elaborating on them is probably out of its scope. And 2 is more of a general programming advice.

015a 5y ago

That's reasonable criticism of my criticism. I would defend myself by saying that it feels like the opposite is also true. I built up a strawman and struck it down, but the recommendations in the original blog post, and here, are defined in extremely abstract terms, then defended with "you can do it however you want, there's no rules" such that every team who implements it will do it differently, and inevitably most will spend years landing on ten bad ways of doing it, never reaching the nirvana of what was promised in the abstraction. I do like the idea; but in a limited capacity, and I'd caution teams from planning an entire application around it. I'd stick to fragments of pages which are highly data-driven, and be more cautious around layout and structure.

hakunin 5y ago
In case anyone else feels that this article leaves enough wiggle room to accidentally end up with something like 015a described, here are the 3 rules I implied in answering the above post: 1. All structure and content goes to backend. 2. Find good names for size-adaptive sections. 3. Responses to write requests can be anything. I think 1 and 3 are covered in the article, but elaborating on them is probably out of its scope. And 2 is more of a general programming advice.