5 ms·

> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too.

> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too. Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.

gt2 6y ago
Guessing he means when the code shared does important things like validation.
kanobo 6y ago
Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.
deleted 6y ago
[deleted]
gwbas1c 6y ago
Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript. (For what it's worth, both are really really cool technologies!) Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
hootbootscoot 6y ago
meteor
deleted 6y ago
[deleted]
fluffycritter 6y ago
What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted. Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client. And if you don't even know which code is running where, that makes it even more dangerous.
- shreddish 6y ago
  Hmm I guess since it's advice to young developers they might make that mistake but any slightly experienced developer knows not to trust anything client side. Not validating data from the client isn't exclusive to isomorphic code.

gt2 6y ago

Guessing he means when the code shared does important things like validation.

kanobo 6y ago

Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.

deleted 6y ago

[deleted]

gwbas1c 6y ago

Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript. (For what it's worth, both are really really cool technologies!) Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.

hootbootscoot 6y ago

meteor

deleted 6y ago

[deleted]

fluffycritter 6y ago

What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted. Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client. And if you don't even know which code is running where, that makes it even more dangerous.

shreddish 6y ago
Hmm I guess since it's advice to young developers they might make that mistake but any slightly experienced developer knows not to trust anything client side. Not validating data from the client isn't exclusive to isomorphic code.