Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
AleCx042312540dAll of those questions get answered by spending time in the actual field developing using either one of them. Which tells me that you are either a student or a hobbyist. Nothing wrong with that.
But what you see as bloated most of us see as battle tested and prosperous.
And your little point about .net mvc and api made no sense to me.
Maybe he's using an old version of webapi where they were still two separate products?
It doesn't really matter if you're doing the work on the server or the client, you're doing the same amount of work. The difference is where you're locating the responsibility. Splitting the responsibility into more manageable pieces can make the code seem more approachable and reduce unit complexity, but the amount of work remains mostly constant.
From a computational complexity standpoint it's an interesting exercise:
As I distribute my applications, my data complexity metrics (flow, boolean inference, structural), and basic Halstead-mass metrics all go up. In that same scenario, my cyclomatic complexity generally dramatically reduces, as does my conceptual branch complexity. At maturity space complexity is also generally much lower for any given impl.
It's always a trade-off. I definitely prefer keeping the api chocolate and front end peanut butter separate.
@AleCx04 I’ve built countless applications ranging from MvCs using symfony/.net to much quicker approaches like express, rails, laravel. I’ve built applications for Disney, cirrus insight and other well known names which leads me to believe your taking my comment much to heart when it’s not meant to be. Large infra today is commonly split up. POCs are pushed so quickly that it often makes little sense to spend a year building requirements that will be inefficient by time they are done. 1 benefit of micro services is the ability to refactor and rewrite without destroying large dep trees. I’ve worked with spring and larger dotnet projects and larger php projects too have been been so large and unmanageable that the company can not afford to keep up, inevitably leading to high churn risk and their end. I might not be a scholar or one with words but I have experience and understand the benefits of not using bloated, highly abstracted frameworks that encourage over engineering
@SortOfTested I get that it’s the same if not more code and work done when splitting services into more repos. Right now though my companies server has 60% unit test coverage with 1700 tests. Our repo is ridiculous in size and our dependencies make a rewrite unthinkable. The proposed way to tackle a rewrite is one service at a time, different repo for each.
I definitely don't support the monolith. Microservices and FaaS are everything to me. That said, I don't see a correlation between fat framework and appropriateness unless you're doing FaaS and runtime spinup is a significant cost. Even in that scenario, you have to compare long-running dyanamic scale costs which naturally compensates for startup time. Even fat frameworks can do microservices. My answer for that context is, it depends on the scale and user load, as well as the ability of that framework to limit itself in memory at runtime.
For context, I won't work on an express project. I would actually quit, because it will impact the quality of the things I care about too much and I can find a project in about a day doing things that won't. The same is true for many people who care deeply about the mechanics of how their code and the software they produce works. Chasing fads doesn't allow you to retain exceptional talent; losing talent guarantees bad software.
There is an idiom that "hardware is cheap, dev time is expensive." That reasoning has been stretched to such a length that it's microns in diameter. I've run the same load, and same complexity on 4 cores and 16gb of ram @ $1300k/month TCO, that a previous client ran on the same platform @ $2.8M/year exclusive persistence cost. The difference was the capability of the engineers.
To your point, every tool has a scenario where it's appropriate. The pursuit of skills reuse is at its best a zero sum game that can lead to the "one platform" anti-pattern. Capable engineers can learn a language and a platform in little time, and therefore cannot be overrated. Developing in-house intellectual capital you intend to keep long term is worth it's weight in gold. Distributed polyglot architectures aren't really limited by complexity, only runtime weight, and engineer skill.
The tldr here would be, appropriateness and skill matters far more than language or framework.
ArcaneEye61240d@SortOfTested @dUcKtYpEd man I love to just stop by devrant from time to time and catch things like you two discussing software. I took a couple weird turns in life and while I know I'm not dumb, it feels like I can just glean a little bit of experience, catch up on the years I lost and the books I didn't read.
@SortOfTested thanks for the links too. I read both articles and while I have no use for it at present, it's good to know things like that exist and where to look for it :-)
IntrusionCM326839dThe thing is: A lot of so called fat frameworks became modular.
Microservices have one essential weakness: Reinvention of the wheel.
It's not _that_ bad when there is a very small amount ( < 5 ) and the micro services are really micro services.
But the more teams and the more microservices... The greater the danger of falling in the trap of reinvention.
Any framework usually has a certain workflow or paradigm.
Utilizing one framework consistently prevents teams from drifting too far away from each other and assures a common ground.
Without this, you'll end in maintenance hell.
The cost for transfering knowledge between teams increases and for every framework you have a plethora of things that could go wrong TM.
Not to mention the fun of new language versions, different behaviour and so on.
Usually any larger (microservice) setup should have a common software stack that either represents a "kind of framework" or is a framework plus X, imho.
AlmondSauce986639dMost spring apps in Java these days will be spring boot, which takes about a week tops to understand what you need to, and not much longer to become completely proficient. Remember that many of these frameworks, spring included, weren't actually written as specific web frameworks - they were generic IoC containers / MVC frameworks that just so happened to only ever be used for web stuff in practice, hence the bloat.
But to answer more generally - I think those sorts of frameworks will go away and be replaced by others as time progresses. There's already hints that Micronaut / Quarkus is taking over in the Java world, and I suspect there will be others in worlds I'm not familiar with. What won't go away are the languages - history shows they take way longer to change, if at all.