The split between front/back-end is an artificial and dangerous one when it comes to code control. There's simply no way to be an effective front-end developer and work strictly on code in the "front-end" layer.
Changes in UX require changes throughout the code. A project that keeps programmers out of the different domains will struggle to improve their UX.
We've seen the same thing with DevOps. If you try to draw an artificial line between what is administration and what is programming, you end up with bottlenecks and problems. There's no problem with have domains of focus, but the idea that you're isolating the code is silly.
I talk about a new definition of a developer in my book. I stand behind more people needing to understand more parts of the project in order to get quality software. Isolation, walls, boundaries, all create problems instead of solving them.
Often I'd start with the feature I want in the front-end, play with it until I recognize what I need in the back-end.
Then implement the back-end feature first. I'll test it with unit tests, with the exact use-case I need in the front-end. This keeps the two bits separated, meaning it works fine with split repos, even with separate release schedules.
Once the back-end is ready, I'll implement the front-end part of the feature.
If you have one repo for front/back-end this is painless. The more repos you have, the more release pipelines you have, the more involved it can be. You need to ensure the backend support is released before the front-end -- though honestly, that's more of a nuance than significant problem.
Note, I'm not perfect at knowing exactly what the back-end feature is that I need. So I will usually work front/back at the same time until I do, then focus on finishing the back-end feature. This requires your code be able to work with working code from multiple repos -- an essential setup need for multi-repo projects.
It probably does. But at the same time, having a very open protocol can make maintenance hard. Your backend no longer has any idea how it's really being used. There aren't specific APIs to optimize, nor specific unit tests for essential pathways.
While the clients are more flexible you can still check what is accessed together in your monitoring and optimize your resolvers and data-stores for it when needed.
I'd even say that the GraphQL spec (which is stricter than the REST spec) allows for optimizations across different implementations of that spec.
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.
The split between front/back-end is an artificial and dangerous one when it comes to code control. There's simply no way to be an effective front-end developer and work strictly on code in the "front-end" layer.
Changes in UX require changes throughout the code. A project that keeps programmers out of the different domains will struggle to improve their UX.
We've seen the same thing with DevOps. If you try to draw an artificial line between what is administration and what is programming, you end up with bottlenecks and problems. There's no problem with have domains of focus, but the idea that you're isolating the code is silly.
I talk about a new definition of a developer in my book. I stand behind more people needing to understand more parts of the project in order to get quality software. Isolation, walls, boundaries, all create problems instead of solving them.
Agreed. So how do you usually go about making changes across frontend and backend as easy as possible?
Often I'd start with the feature I want in the front-end, play with it until I recognize what I need in the back-end.
Then implement the back-end feature first. I'll test it with unit tests, with the exact use-case I need in the front-end. This keeps the two bits separated, meaning it works fine with split repos, even with separate release schedules.
Once the back-end is ready, I'll implement the front-end part of the feature.
If you have one repo for front/back-end this is painless. The more repos you have, the more release pipelines you have, the more involved it can be. You need to ensure the backend support is released before the front-end -- though honestly, that's more of a nuance than significant problem.
Note, I'm not perfect at knowing exactly what the back-end feature is that I need. So I will usually work front/back at the same time until I do, then focus on finishing the back-end feature. This requires your code be able to work with working code from multiple repos -- an essential setup need for multi-repo projects.
"There's simply no way to be an effective front-end developer and work strictly on code in the "front-end" layer."
I have the feeling solutions like GraphQL change this, by simply giving the front-end more control.
It probably does. But at the same time, having a very open protocol can make maintenance hard. Your backend no longer has any idea how it's really being used. There aren't specific APIs to optimize, nor specific unit tests for essential pathways.
While the clients are more flexible you can still check what is accessed together in your monitoring and optimize your resolvers and data-stores for it when needed.
I'd even say that the GraphQL spec (which is stricter than the REST spec) allows for optimizations across different implementations of that spec.