Hacker News Reader

Comment by btbuildem | Hacker News Reader

Another argument for keeping business logic server-side is, well, that your proprietary and presumably valuable code remains on the server instead of being widely disseminated.

View on HN

This is my biggest issues with SPAs. Its not that it is that hard, its just so much easier to keep it secure if its being done server-side.

What's an example of something that would be proprietary, reasonably on the front-end, and stealable from minified source?

In my mind, anything complex would probably be server side anyway for performance reasons (though I admit there are many, many SPAs with seemingly little thought about performance.)

Anything you would normally stash in an API gateway.

API keys, anything that handles auth, etc.

An inexperienced dev might do something like put API keys in frontend code. You can even do an advanced search of Github to find people's keys to steal to get access to paid APIs.

Inexperienced devs already leak keys into front end code before SPAs.

And the opposite to that argument is that making an SPA gets you an API "for free". If you want users to be able to write their own code that interacts with your platform, it might be beneficial not to write multiple server-side interfaces and to "eat your own dogfood".

Wouldn't the actual business logic remain behind an authenticated API endpoint? Even your relational data models would probably be turned into something more like a tree.

Only if you're going full REST will there be a risk of client-side business logic.

Equally, you can't build a server-side app that works offline. There's arguments for and against regardless of what you choose.

Reply on news.ycombinator.com