3 ms·
Another argument for keeping business logic server-side is, well, that your proprietary and presumably valuable code remains on the server instead of being wide
by btbuildem 8y ago
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.
- Eire_Banshee 8y agoThis 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.
- tyre 8y agoWhat'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.)
- Eire_Banshee 8y agoAnything you would normally stash in an API gateway. API keys, anything that handles auth, etc.
- creatornator 8y agoAn 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.
- Can_Not 8y agoInexperienced devs already leak keys into front end code before SPAs.
- ppeetteerr 8y agoWouldn'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.
- onion2k 8y agoEqually, you can't build a server-side app that works offline. There's arguments for and against regardless of what you choose.
- dvdkon 8y agoAnd 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".