4 ms·

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how the front end receives and displays the data; for example, to properly implement Backbone, you want a RESTful API. Is this available (or achievable if not)? You have to know your capabilities in order to appropriately choose a pattern or framework. You're involved- or should be involved- in coordinating with back-end developers on the interface from the front-end and the back end. The implementation of that interface depends on the structure of the underlying system; different databases, such as document-based vs relational, can have subtle differences in how your interfaces are implemented and effect the flexibility of said interfaces.

Zimahl 14y ago
You only need to coordinate inputs and outputs. If you need to coordinate more than that you've probably got a very coupled system. Especially with web services - REST, SOAP, etc. - who cares if the front end is connecting to a Java application or a .Net application? Who cares if what the FE dev is building is IOS, Android, JSF, Spring, Flex, etc.? If it's done right, all the details can be (and should be) abstracted away from the FE.
- ajacksified 14y ago
  My entire point is - who defines this REST / SOAP / "who cares" layer? If it's strictly back-end engineers, front-end interoperability is not represented. A FE engineer involved in the development and maintenance of this API layer ensures that concerns are effectively recognized - which requires an FE engineer who knows the whole stack. Yes, these details should be abstracted away from the strict implementation of the actual FE code, but that API has to be created in concert.
  - Zimahl 14y ago
    who defines this REST / SOAP / "who cares" layer Definition of an API isn't about knowing the 'entire stack'. A front end dev will need to understand the structure of the API and present needs to whoever is maintaining it but it doesn't matter what the API is coded in since that is most likely abstracted away via the different service interfaces. Frankly, other than what they are developing the front end in, the only aspect a dedicated front end developer needs access to is the document describing the API so they can make changes there and get their needs to the API owner.

Zimahl 14y ago

You only need to coordinate inputs and outputs. If you need to coordinate more than that you've probably got a very coupled system. Especially with web services - REST, SOAP, etc. - who cares if the front end is connecting to a Java application or a .Net application? Who cares if what the FE dev is building is IOS, Android, JSF, Spring, Flex, etc.? If it's done right, all the details can be (and should be) abstracted away from the FE.

ajacksified 14y ago
My entire point is - who defines this REST / SOAP / "who cares" layer? If it's strictly back-end engineers, front-end interoperability is not represented. A FE engineer involved in the development and maintenance of this API layer ensures that concerns are effectively recognized - which requires an FE engineer who knows the whole stack. Yes, these details should be abstracted away from the strict implementation of the actual FE code, but that API has to be created in concert.
- Zimahl 14y ago
  who defines this REST / SOAP / "who cares" layer Definition of an API isn't about knowing the 'entire stack'. A front end dev will need to understand the structure of the API and present needs to whoever is maintaining it but it doesn't matter what the API is coded in since that is most likely abstracted away via the different service interfaces. Frankly, other than what they are developing the front end in, the only aspect a dedicated front end developer needs access to is the document describing the API so they can make changes there and get their needs to the API owner.