The Great Divide: Frontend and Backend Developers
More often than not, there is a division in resources between what is often called “frontend” developers and “backend” developers in software development today. At least for us at QAT Global, this division exists because of the considerable investment of time, talent, and experience it takes to be really good at either of these disciplines. Sure, most developers can put together a web application and code the frontend and backend, but will it pass the test of time?
- Will it need to be “updated” in a year?
- Will it pass a PEN test?
- Does it include automated performance testing?
- Will it scale automatically?
- Does it leverage cloud technologies?
- Does it leverage industry-proven enterprise patterns and practices, or will it simply “work” by the developer’s definition and then need to be “re-worked”/rewritten based on a new requirement?
It might sound crazy, but we have customers who believe standards and practices are not needed since the next developer in the code will just rewrite everything anyway.
Blazor Enables Leveraging Resource Investments That Matter
QAT Global looks to leverage the investment we have made in our C#/.NET Core resources, and Blazor enables us to do just that. When considering a traditional web development project, you most likely need a team of frontend and backend developers. In terms of the total requirements that need to be implemented, rarely are they equally split between frontend and backend. Often once the backend API is built, the remaining requirements are frontend related. So even if just half of the backend developers were able to be “full-stack” developers on a Blazor project and implement some of the frontend requirements, the impact on the project, deliverable dates, and go-live date would be significant.
Is a Full-Stack Developer Really a Full-Stack Developer?
Full-stack developers, who are equally proficient in frontend (client-side) development and backend (server-side) development, are great if you can find them. But in our experience, what you often end up with, based on a resume indicating “full-stack developer,” is a really good frontend developer who can basically code some SQL in a controller on the backend. For an exhaustive discussion on this, see https://css-tricks.com/ooooops-i-guess-were-full-stack-developers-now/. This article is exhaustively long and deep. Still, even if you just scan the discussion, you can see the same problems and division or delegation of work between frontend and backend resources, and all with good reason.
Leveraging Blazor to Deliver Results for Everyone
But with Blazor, from a QAT Global point of view, all those bullet points from Microsoft listed at the top of this article are precisely why we are using Blazor for our customers. For QAT Global, each bullet point adds value for our resources, customers, and the bottom line.
Now with Blazor, we have an opportunity to overcome, at least some, of the frontend/backend resource challenges we’ve mentioned, the “great divide,” by leveraging our C#/.NET core resources and letting them develop “closer to the browser/frontend.”
QAT Global is not:
- Pondering the idea that Blazor is the “next latest and greatest” technology that will transform web development. Been there done that with CGI Perl, Struts, ASP.NET, etc.
- Trying to capitalize on the idea that we should jump on the Blazor bandwagon early and catch the wave. Been there done that also with Enterprise Java Beans.
- Looking for another proprietary technology that has a lot of hype but little to no third-party support or does not embrace open-source standards.
QAT Global is instead:
- Looking to leverage open-source technologies, frameworks, and tools that have been and will be around for years to come in order to maximize our customers’ investment and decrease their maintenance costs.
- Building non-proprietary solutions that clients own, operate, and maintain.
- Creating enterprise solutions using proven enterprise patterns, practices, tools, and technologies.
We don’t want to simply build for you, but instead, we want to build with you something that will serve your business and your customers for years to come. As a result, we tend to be pretty picky when it comes to our technologies.