4 ms·
> 1) It makes no difference at all if is the server is implemented using a different language than the client. Makes a difference: Same people can maintain it
by egeozcan 10y ago
> 1) It makes no difference at all if is the server is implemented using a different language than the client.
Makes a difference: Same people can maintain it without too much friction.
> 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.
Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.
- electrotype 10y ago> Makes a difference: Same people can maintain it without too much friction. For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript... > Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides. Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer. But I guess it's not that important if your backend will only be consumed by this particular application, ever.
- egeozcan 10y ago> Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. We have a server which exposes validation logic as a generated JS library (no server-side JS yet but we plan switching to Typescript) and that is used across many (more than 10) clients. I don't see any coupling. Changes in your models break the API regardless of you sharing anything.