In sensible work environments, that's solved by aligning incentives at project level. If your frontend team crucially needs something done, but the backend can't give a shit, the problems run deeper than area of responsibility IMHO. Either what the frontend works on doesn't matter, or the backend team wants to sink the ship, or there's way too many fires to put out and the ship is already sinking.
Having mega teams or filling them with jack-of-all-trades types also has critical downsides.
The simple result I get introducing the concept: https://medium.com/mobilepeople/backend-for-frontend-pattern...
If there is only one front end that talks to the back end, then yes I agree. If there are 20 different front ends from 20 different teams, some of them external, that are expected to talk to the same API, then it makes a lot more sense.
In other words, have a team with front and back-end devs working together, with a frontend acting as a sensible default interaction to an API. This can be something as simple as a widget or component.
This front end is expected to have a full suite of tests running through the API (or an api test device -- this test device can also be used to better communicate the requirements to backend devs), and be well documented in how and why it's doing something.
That acts as an example for any other frontends. When they have questions or issues with the api, it also provides an immediate source of truth to show how to properly do something. And it provides confidence that the API is behaving in the expected fashion for the user experience being provided for.
Just a thought.
In one project we were rebuilding an old outdated UI. We started with being very strict about literally only implementing what was needed for frontend, for example not even a GET /widgets/{id} until there was a UI that needed it. We also explicitly built new models for this, separate from our database models, so it wasn't just "return everything in the table": if the UI only displayed half the fields, that's what was returned. A big benefit of this mindset was when we needed a list of things from joining multiple tables, there was no thought of pushing this to the front-end; we just made a viewmodel, did the work server-side and returned it.
Also, pretty early on we implemented Swagger (OpenAPI) and built in docs to our code. This helped establish it as a part of dev and the coding style that any new devs quickly bought into, as opposed to an afterthought everyone sees as a chore.
After we had a a dozen or so APIs done, we started opening it to customers. We'd add new things they'd request (but our UI didn't need), but strictly kept the use-case-first mindset, as well as continuing the UI port (page-by-page, effectively). Even a few years later, the feedback from our developer users was overwhelmingly positive, along the lines of "this is the best API I've ever used".
I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.
Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why.
The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.
Or just use GraphQL-esque methods, but versioning will poke its head in somewhere eventually.
That was obviously a really general rule of thumb not intended to be an actual architecture guideline...
Don't get me wrong, I quite like Java and the good tooling, but I'm more exposed to C# these days and Java feels like 90% the same, so I'm never compelled to go back.
Or you are maybe sarcastic, impossible to tell in text...
Side-edit: from the very beginning, Java was simple, when it was released. But in 2010 it felt super confusing to me.
Is it? I come from a very different background and I'm trying to get a small Java back-end up and running (Quarkus) and wow, it's so painful! There's a huge amount of buy in, to me, in the framework. I found Node, Go and Python to be easier in simply delivering a HTTP(S) server. I've gotta do it in Java for reasons.
Spring is just a few annotations away from creating an endpoint.
Of course with spring, there’s a lot of stuff that isn’t java that you have to know.
However, the Spring framework in the 2000s was a horrible mess of "aspect oriented programming" and obscure XML configuration files. Till this day I had no idea what it was trying to achieve with that architecture (except maybe trying to avoid writing code by writing lots of XML configuration files instead)
I think they learned their lesson.
const app = express()
app.get("/user", (id) => { return db.user(id); })
app.run() or something like that.
That coming from experience of managing various shit turborchargers like tomcat or jboss that just added tons of unnecesary complexity and zero benefits to 90% of apps that used them
LifeRay, not even once.
There does need to be oversight over whole thing to avoid exactly what is described above.