4 ms·

But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is : 1) It makes no

But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is : 1) It makes no difference at all if is the server is implemented using a different language than the client. 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.

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.
Roboprog 10y ago
I realize you are critical of that viewpoint, but point 2 seems really wacky to me. Current big project at work has a back end that is not in JS, but we still have a way to run the same validation code on both sides, which is run in an embedded JS interpreter on the server. I'm not sure I would want to write a complete back end in JS or not (even if I'm not in love with Java, lately), but reusing this part makes a lot of sense. --- We currently serialize (sync block) validation requests on the server through Nashorn, rather than having multiple instances (per thread or a pool). But, it's not like the requests wouldn't be serialized through Node, though. The rest of the request processing happens on independant threads normally. Not overly fond of threads, but I don't think I could get my team to by into Erlang or Elixir :-) For that matter, my primary partner on this project is a big Scala fan, and we couldn't even get the rest of the group to go for that :-(

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.

Roboprog 10y ago

I realize you are critical of that viewpoint, but point 2 seems really wacky to me. Current big project at work has a back end that is not in JS, but we still have a way to run the same validation code on both sides, which is run in an embedded JS interpreter on the server. I'm not sure I would want to write a complete back end in JS or not (even if I'm not in love with Java, lately), but reusing this part makes a lot of sense. --- We currently serialize (sync block) validation requests on the server through Nashorn, rather than having multiple instances (per thread or a pool). But, it's not like the requests wouldn't be serialized through Node, though. The rest of the request processing happens on independant threads normally. Not overly fond of threads, but I don't think I could get my team to by into Erlang or Elixir :-) For that matter, my primary partner on this project is a big Scala fan, and we couldn't even get the rest of the group to go for that :-(