But in the end, the GraphQL API is still consumed by another IT system, not a human.
GraphQL is just another way of accessing the backend, just like REST, SOAP, exchanging raw byte data, etc.
It doesn't change the overall structure of the backend as a system.
that was kind of the question. Would you expect a FE developer to be able to form a GraphQL query to get the data that they need or would you expect the BE Developer to tell them what the query needs to look like.
Why would this be of any relevance for my idea of backend and frontend developers?
It literally does not matter if the frontend dev writes GQL queries theirself or get them by a backend dev.
Ideally, the frontend dev should be familiar with the interfacing technology used - whether it's GQL, REST, or something else. It's their job to gather the data provided by the backend.
I think it is critical as to where the line is drawn between FE and BE which is why I asked the question. Would you expect your FE developer to be able to structure a complex query to fetch the required data efficiently, or would you expect the BE Dev to develop the data Map that the FE then renders
For a concrete example.... Although I was doing both BE and FE on this project I had data that was in 4 dimensions: style, size, colour, location. Do I take the computational hit and create nested JSON of all attributes which makes presentation easier (equivalent to a noSQL document model) and if so so I so size in colour or colour in size, or just use object keys and dynamically map the data from the arrays using their keys (more like a RDBMS model) the latter is more flexible but requires run time overhead. The former is probably more responsive but with a larger time to first interaction and only optimised for one access pattern.
Personally I would only expect a Senior Dev to be able to make that call and in reality it is more likely to fall to the BE dev to structure the data as required for consumption by the FE. Not saying that is right, just practical reality. And if that is the case should the multi -level JSON object be created at the database or API level where there is likely to be more processing power and the ability to cache the model.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Front-end developers build applications primarily used by humans.
Back-end developers build applications primarily used by IT systems (computers, other applications e.g. front-ends, etc.).
Is a GraphQL query front end or back end?
The query is crafted by the user but the resolver is designed by the API team
But in the end, the GraphQL API is still consumed by another IT system, not a human.
GraphQL is just another way of accessing the backend, just like REST, SOAP, exchanging raw byte data, etc.
It doesn't change the overall structure of the backend as a system.
that was kind of the question. Would you expect a FE developer to be able to form a GraphQL query to get the data that they need or would you expect the BE Developer to tell them what the query needs to look like.
Why would this be of any relevance for my idea of backend and frontend developers?
It literally does not matter if the frontend dev writes GQL queries theirself or get them by a backend dev.
Ideally, the frontend dev should be familiar with the interfacing technology used - whether it's GQL, REST, or something else. It's their job to gather the data provided by the backend.
I think it is critical as to where the line is drawn between FE and BE which is why I asked the question. Would you expect your FE developer to be able to structure a complex query to fetch the required data efficiently, or would you expect the BE Dev to develop the data Map that the FE then renders
For a concrete example.... Although I was doing both BE and FE on this project I had data that was in 4 dimensions: style, size, colour, location. Do I take the computational hit and create nested JSON of all attributes which makes presentation easier (equivalent to a noSQL document model) and if so so I so size in colour or colour in size, or just use object keys and dynamically map the data from the arrays using their keys (more like a RDBMS model) the latter is more flexible but requires run time overhead. The former is probably more responsive but with a larger time to first interaction and only optimised for one access pattern.
Personally I would only expect a Senior Dev to be able to make that call and in reality it is more likely to fall to the BE dev to structure the data as required for consumption by the FE. Not saying that is right, just practical reality. And if that is the case should the multi -level JSON object be created at the database or API level where there is likely to be more processing power and the ability to cache the model.