Hacker News new | comments | ask | show | jobs | submit login
Ask HN: Why do I need server code in 2014?
10 points by arisAlexis on Mar 20, 2014 | hide | past | web | favorite | 6 comments

I am building a web app looking to sharpen my skills and do my dissertation. Can someone explain to me why do I need server side ruby/java/node.js when I can have a db with a restful api automagically and angular? Am I missing something? Is authentication the only issue?

Depending on what you're doing, you can perhaps have an authenticated client do things which are not authorized. This can mean that you have to do things server-side to enforce business rules.

Example: I had an inadvertent trust-the-client situation where I let Javascript decide if someone's credit card was going to be charged. I did not anticipate that anyone's computer would ever be hit by a lightning bolt during a transaction, and as a consequence my server got 24 callbacks and dutifully charged the client's card 24 times.

Sometimes authenticated clients can abuse the system intentionally, depending on what you're doing with it.

You will likely discover at some point that your service has to interact with other services, which may or may not be easily doable with a particular client orchestrating all of the work itself.

Depending on your problem domain, you may need to do things on behalf of a client when that client is not connected to the service/the Internet/etc. This counsels having a non-dumb server side piece available.

There exist many other reasons one could name. What are you thinking of doing in your dissertation?

"Client" and "server" are overloaded words with multiple meanings. Let's break this down a little.

The important distinction is between "a machine that runs code you control" and "a machine that runs code controlled by someone else". In general, if the code is running on someone else's computer, you don't control it. This is very true for browser Javascript, which visitors can alter at will, but even signed iOS applications are vulnerable to determined attackers.

In practice, 99.9% of users won't do this. Especially if the only thing at stake is your dissertation. But in many cases the 0.1% would be enough to potentially bankrupt you. That simple "RESTful API" can be used to delete your database, or (far worse, in many cases) insert fraudulent data… unless the database is protected by authorization logic that you control.

(Authorization logic is no laughing matter. It's generally application-specific. Is it okay for an arbitrary user to add 1 to this database column? Depends on whether the column represents "number of visits per day" or "number of dogecoin paid out per second". Repeat this design exercise for every possible permutation of every transaction. Then watch what happens when you accidentally let user X publish unsanitized text to a column which will eventually be printed verbatim on HTML page Y containing script Z...)

To control a piece of code, you have to run it on a machine that is physically secure, and that nobody but you ever touches. If it is networked, the machine must sit at a documented, permanent location on that network (i.e. "have an SSL certificate vouching for its IP address"), and be behind a network firewall to keep the attack surface down. At which point, no matter what it looks like or what ports it listens on, this machine is going to be called "a server".

And once you've accepted a server into your system you may as well take advantage of it: You can use programming languages besides Javascript, runtimes other than a browser, APIs that browsers don't have, hardware that browsers can't access, and much richer interfaces to your data than REST.

It is also true that the boxes we call "servers" are designed to run 24/7, have more durable and redundant network connectivity, have redundant power, have fast pipes connecting them to other servers, and be rented by the hour for a few cents. But, compared to the issues of ownership and control, these are implementation details.

Also interested in answers - posting as a lazy bookmark! :)

No need for placeholder comments, instead:

1. Click the up arrow on the submission.

2. Click on your username in upper right hand corner.

3. Click on "saved stories". The upvoted story should be there.

Thank you - will do this next time :)

after spending nights awake I found this closest to my liking and I will give it a try https://www.arangodb.org/foxx

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact