Having a front end grid component fetches its metadata from the backend, is this a "bad" strong coupling?

Question

The idea is that for each resource we want to dispaly in a grid, there will be one endpoint for data and another for metadata.
The metadata endpoint will bascially return a list of columns and their types based on the POJO being displayed.

From one point of view, I can see the productivity gain with this approach. However, a lot of team members are against this approach because it is a strong coupling.

I feel that this is just repeating a mantra.

I am arguing that any frontend web app is coupled with its backend, we are not developing a generic web app that can be plugged and played with any existing backend so why is a stronger coupling with our backend a bad idea?

Is this approach a bad idea from a software design perspective?

Answer 1

If your frontend is generated on the backend side and is returned as HTML then stick with that.

If your're frontend is Single Page Application and you're using AJAX calls then expose your view model trough api endpoint.

Why do you want to have two separate endpoints with data and metadata? If it's for one view only then expose one endpoint wich will return merged data and metadata as one view model. Unless you want to reuse data and metadata in different use cases, but even then I would create one endpoint with view model needed in the given use case.

[EDIT]

Coupling is needed, without coupling our systems would not work.

In your case, if your API evolve together with your frontend, so every change to the resource/model need to be reflected on FE due to business requirements, then it's a "good" coupling.

If your API is shared between FE and multiple other clients and those clients are pushing changes to the resource/model so that it become "inconvinient" for the FE to use, then that's "bad" coupling.

While thinking about coupling you aslo need to consider stability of given dependency. So if given dependency is "stable", it doesn't change very often, then it's "safe" to be coupled. If given dependendy is "unstable", it's API/contract changes very often, then it can be pain to be coupled. Like in human relationships :D

Answer 2

The simplest and most maintainable way to have a front-end is for the "resource" to generate its view. No "endpoints", front-end interpretation necessary. Just output the HTML. Job done.

And if the "resource" changes, well, you'll have a single place to make all the changes.

In contrast, if you have an additional remote call, front-end code, etc. You'll likely have to change both sides when something changes. Some new UI feature will force a change in your remote call, because you have to deliver some new piece of data. Same if the data model changes. So high likelihood of both sides changing. This is the strong coupling your colleagues may refer to.

I am arguing that any frontend web app is coupled with its backend

That may be true, but why even make a separate frontend web app? Is the frontend written by third parties? Are you trying to support unknown front-ends not developed by you? If not I see very little reason to split the front-end capabilities from the "back-end". It just makes everything so much more complicated.