I just published a blog post about the most common objections developers seem to have against full-stack development.
First there is the idea of separating different technologies from each other. But they’re not also building a separate database access application to keep SQL out of their business logic. And then there’s the concern that it just be too much for a single developer to handle it all. But that’s only if you build everything from scratch using assembler rather than using appropriate frameworks and tools. And then finally there’s the objection that a separate REST API will anyways be needed for other reasons. But that’s no reason to make the web UI worse.
Are there other objections that you hear about often? Do my counterarguments make sense? Are there other arguments that I’ve missed?
Hey @Leif,
Thank you for making your point so clearly. I am sure that you are not alone on the hill. I’m also a big fan of full-stack development. Of course, it’s not the solution to all our problems, but it can significantly increase developer productivity and satisfaction in many projects. Unfortunately, I’ve also worked too often on projects where frontend and backend teams worked separately. However, this was usually an organizational or perhaps even political decision that was often made so far in the past that none of the current developers can still say exactly why this decision was made. I’m always happy when I can work as a full-stack developer or in a full-stack team. Ideally with a framework like Flow or Hilla :)
There are even front and back teams that tend to hate each other a bit in the same team, due to poor or bad communication.
At least modular projects with Vaadin are good too, the fact of not maintaining endpoint saves you a lot of work, currently, all you hear is microservices, but not everything should be all microservices and DDD…
From more than 40 years of experience I will suggest the following simple logic as to why I think Vaadin is on the right track for business applications.
Having a thorough understanding of the business domain is the basis of constructing a useful and correct application. When learning about the business domain you have to gather information from many sources, some are end users that understand everything through the UI, some are business rule experts and others know a lot about the data (model).
Learning everything about a large business domain is beyond most people, but learning about a more specific, narrower part is possible, as is learning everything about a small domain.
The UI, business rules and data model are all part of constructing the best possible application, so you as a developer must have full control from data to UI, and there is a lot more to doing that right than meets the eye, when talking IT architecture.
Point is, Vaadin enables us to group according to vertical business domain slices, which I consider to be much better than the somewhat artificial splits due to some arbitrary choice of tools. That is one less communication barrier.
Of cause you need some guidelines for design etc., but that is independent of tools and you probably need someone to align the data model from time to time, because I tend to see the DB as an integration layer, the last line of defense that must hold, but maybe I’m biased from my early years in the business.
I see a contradiction here even though I also recognize both points. Or maybe it’s a self-fulfilling prophecy?
Those objections are indeed very hard to address but I think one promising approach is the one from the previous post and the webinar: full-stack was the original norm from the PHP era and the current raise of full-stack frameworks offer an opportunity to return back from the exceptional circumstances that we had with the standalone SPA frameworks.
At the same time, it’s important to remember than any changes affecting team compositions in companies are panning out over multiple years. It’s not something that changes overnight.