

Ask HN: Why do I need server code in 2014? - arisAlexis

Hi,<p>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&#x2F;java&#x2F;node.js when I can have a db with a restful api automagically and angular? Am I missing something?
Is authentication the only issue?
======
mechanical_fish
"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.

------
patio11
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?

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

~~~
runjake
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.

~~~
markovbling
Thank you - will do this next time :)

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

