How is decoupling client side from server side possible?

Question

I am struggling with the concept of loose coupling when it comes to SPA client side apps and API/REST backend. Everyone seems to say that it is bad practice to tightly couple front and backend code and I understand why.

But my question is how is it possible to keep them loosely coupled in scenarios where both the server and client apps require the same models and can make changes to those models? I would imagine you would have to duplicate code for the model declarations (which is also bad practice) or have the client code know about the model structure of the backend.

For example, lets say I'm writing code like object.someprop = 'some value' on the client but someprop is no longer a property or is updated on the server. I then have to update the client side as well which to my understanding falls in the category of being tightly coupled.

It seems that even to write something like object.someprop on the client side is incorrect. But if I don't how can I allow users to interact with the data?

Could someone give me some information on what's supposed to happen here?

Answer 1

There will be a dependency of the client toward the interface that the server provides, for example a REST interface, graphql, a flatbuffer, etc. This interface can be seen as a contract that the server and client agree to. This does imply the data structures provided and is a form of coupling . Hence the need to clearly describe / define APIs and have a policy for versioning and obsoleting those - At least if there are multiple clients consuming the API and client and server cannot be released at the same time. For a basic webapp with only a html client that the server produces you may be able to skip the API versioning.

So this may seem like a tight coupling at first glance, but does not have to be. Client and server may or may not use the same language / representation of the data. All they have agreed to is the way of access and the transport format. Usually there are additional transformations to/from the transport format, for example JSON to javascript object. And the client is free to do whatever it wants the with the JSON in this example. It may use all the data or just a single attribute. All of that is of no concern to the server. Similarly the client is not concerned with how the server has created this JSON string. It could be implemented in golang and have a completely different internal representation - The client would not know. Due to the service contract only describing the interface and the resulting freedom for server / client implementations the coupling can be considered loose (enough).

In your specific example you seem to be describing a scenario where you use javascript on both server and client and you are wondering if you can use the same code base (at least to represent the objects). You can do that for the interface portion (check out the graphql approach ), but you are usually better off using separate, internal object types on the server because often you will find the need to add additional attributes, references for internal processing purposes or ones that would be insecure to give to the client (think passwords, privacy relevant data, secrets, etc.).

Answer 2

You have to distinct between loose coupling and inheritance in a more broad sense than just subclassing. When you need exactly the same models to be reused by both client and server - that's perfectly fine and quite normal thing to do. You simply introduce Shared assembly (sometimes also known as Core ) and define common things (including abstract classes which suppose to have different implementation with respect to client/server necessities) there. That does not mae things tightly coupled unless you did not bother to separate interfaces from implementations , OK? Loose coupling is all about depending upon interfaces/adtract clasess rather than concrete implementations: you could share somewhat common implementations, but even then both client and server shouldn't, generally speaking, rely upon them; inputs/outputs of all the functions have to be implementation-unaware.