
The awkward journey towards less back end - wolframhempel
https://medium.com/@deepstreamIO/the-awkward-journey-towards-less-backend-a260a16095de#.jlwlwkp2r
======
donatj
I have always been of the mind that the actual things of value your app does,
the parts that actually make money, it does server side. That hasn't changed
with single page apps and phone apps. Our back end has slimmed but the things
of actual value, the things others don't offer all happen server side. For
instance in our case most of the "magic" takes place by processing hundreds of
gigabytes of combined users data, data we couldn't send to the front end for
reasons of both volume and privacy.

~~~
troika
Yup, but we've build this trading app
[https://vimeo.com/143728632](https://vimeo.com/143728632) using just
deepstream - it does get you quite far

~~~
pheeney
The website and twitter account appear offline. Is there more information
about the technology somewhere?

------
StavrosK
It's not towards "less back end", and it's not "awkward". Since the dawn of
time, everyone has been trying to do more stuff with less energy. Backend,
frontend, transportation, everything. That's why there are frameworks, and
that's why, these days, we're fortunate enough to be able to glue a heap of
libraries together and pretty much only need to write the functionality that's
novel.

I think that the author is doing everyone a disservice by framing it like
that. I don't even know where to begin to detail where he's wrong: Backend
devs are the first people who want to write less backend (they're the ones
writing all the libraries!), deepstream isn't a novel idea (it looks like it
makes the 90% easy and the 10% horrible), pushing all the code to the client
isn't a good idea (just imagine how long it would take to update every client
when you discover a critical bug, rather than the three minutes you can update
the server), etc etc.

It's a nice service that will allow people to prototype much faster and more
easily, and I guess the controversial stance and title of the article worked
very well for getting the clicks.

------
falcolas
This feels like clickbait around an advertisement. They are offering your
basic CRUD DB operations via an API, and throwing in DB triggers as a bonus.
This doesn't strike me as a hard problem to solve, if I'm honest; especially
in a world where GAE, Lambda, Flask, and Rails exist.

~~~
tootie
It's an iteration on those frameworks. Not ground breaking, but it's a new
option.

------
tech2
Concepts like this seem fine a lot of the time for simple apps, but eventually
you're going to want to _do_ something with the data. Query its history,
integrate with other systems, etc.

I read an aphorism of sorts a long time ago that basically stated that your
software is _relatively_ unimportant, it's the data that's you should worry
about. Think about that before trusting that random system X can handle your
data for you.

~~~
Svenskunganka
Since Deepstream just plugs into whatever database you want to use, you still
have the possibility to query history, integrate with other systems, and so on
- without using Deepstream at all, but at the same time you can do that using
Deepstream as well.

------
inestyne
Imagine a world where your given 5 million dollars and a business model; the
only real guard rail being 'don't walk us off a cliff...'. It's not fun and
games anymore is it?

A huge percentage of the code I write has nothing to do with the front-end. Am
I going to hang my project's fate on a platform created solely with quick and
cheap front-end development in mind? Probably not.

I do remember the bad old days when all you really had was a thick native
client, a database, and scheduled tasks. So there is precedence, i'm just not
sure it's good one?

:)

I like Node, I like Meteor, not ready yet, but close. I like the idea of
sharing logic, data, and state that way. Not happy about the sideways
protocol. Leaves Node available for the crap I don't want to run on the
client.

Pretty sure the magical disappearing back-end (OP) idea is a dead end tho.

------
notacoward
The funny thing about this is that the _actual_ back end - i.e. the thing that
provides all those high-semantic-level services to the front end - is becoming
more complex than ever. What this author calls the back end (and which I would
call the back-end interface) of an application previously only needed to serve
that application's particular needs and usage patterns. As the front/back line
moves so that the same logic becomes part of the back end, it now has to
satisfy any possible need or usage pattern - including many that will never
actually materialize. As data structures move from the front end to the back
end, more code must be added to provide security for them.

This is all great for reusability etc. but it _does_ add complexity (including
failure complexity) and overhead. As always, such decisions require deep
understanding of the tradeoffs involved, and sober judgment of whether the
effort is worth it. Only time will tell whether such understanding and
judgment will be the norm or the exception. As a grumpy old programmer, I
think you can guess where I'd place my bets. ;)

~~~
pluma
Case in point: ArangoDB lets you run "backend code" directly on the
database[0]. This allows the "backend interface" to become a dumb client
without adding external services to the stack.

[0]: [https://www.arangodb.com/why-
arangodb/foxx/](https://www.arangodb.com/why-arangodb/foxx/)

(Disclosure: I work on ArangoDB Foxx)

~~~
madeofpalk
You mean 'stored procedures'?

~~~
pluma
If you want to define "stored procedures" as "application code running in the
database", yes. But traditional stored procedures are to ArangoDB Foxx what
"copying files with timestamps on a network drive" is to version control.

~~~
mixedCase
It's so funny that someone even downvoted you for calling him out on his bs.

Databases like Postgres can run languages like JavaScript or Python for their
stored procedures. ArangoDB does nothing new in that regard.

~~~
pluma
Let's try a more detailed comparison:

Stored procedures are typically used for access control, data validation and
code re-use. Foxx can of course be used for the same purposes.

However while no sane person would want to expose a Postgres database to an
external client, Foxx can be used to create REST APIs.

There are proposals to add an HTTP API to Postgres so I would assume that
there is a lot of demand for such use-cases.

So stored procedures are just the basis and extensions like the ones Postgres
plans to build on top of them are comparable to the native Foxx framework
ArangoDB has already been offering for years.

It's also possible to use user-defined functions in ArangoDB's query language,
which are a more obvious equivalent of traditional stored procedures in SQL.
Unlike these functions Foxx allows developers to build entire data-centric
microservices. Additionally Foxx provides access to a wide range of JavaScript
libraries via support for Node.js-style modules.

~~~
mixedCase
If what you need is a REST API there are solutions for it that use Postgres,
namely [http://postgrest.com/](http://postgrest.com/)

~~~
pluma
If you just want a REST API for your database, sure, PostgREST does that for
Postgres. But Foxx lets you specify your own endpoints, not just expose the DB
via REST (which ArangoDB already can do out of the box). IOW: if you just want
to talk to your DB over REST and manipulate documents directly, ArangoDB's
native REST API is the equivalent of PostgREST.

If you want arbitrary HTTP endpoints with logic you define yourself, bundled
as isolated modules with an express-like router API, Foxx is currently the
only way to do that within a database. It allows you to colocate your data-
centric application logic with the data it operates on (or even remove the
need for exposing sensitive data altogether by handling application-level
auth/auth within the database).

The only equivalent I can think of personally are CouchApps in CouchDB but
they are necessarily far more limited in scope (because CouchDB isn't built to
support complex or ad hoc queries).

~~~
ruslan_talpa
"But Foxx lets you specify your own endpoints ... Foxx is currently the only
way to do that within a database" ... so you mean like
/rpc/storred_precedure_name in PostgREST :)?

(don't get me wrong, anyone capable of writing a db from scratch is a genius,
good job and good luck)

------
michaelbuckbee
I think this is interesting, but perhaps not described the best way in this
piece.

I'd say it's more along the lines of a Parse like service where:

\- you own your data

\- you choose your datastore

\- you get an easy to develop against service for client interactions without
sacrificing back-end flexibility (aka you can still run SQL queries for
reporting)

------
nbevans
"In the olden days, being a backend developer meant that you wrote a long list
of functions that mapped to HTTP requests. A post to /item/14 was turned into
createItem( id ) — and we liked it that way."

That's not true at all. A good place to stop reading.

~~~
asimuvPR
That part had me read further multiple times. It was hard to understand the
point behind the post. Its an obvious advertisement for a product but it could
have at least provided a better explanation of why a simple data store may
prove to be more effective for applications that are CRUD front ends. Instead,
the post tries to sell the benefits of a data store that can be expanded with
backend services. Which is funny given the title.

------
erikb
I didn't really get what it wants to do different than CouchDB. If you call
your data access a database or an app or whatever doesn't change that it is
what it is.

------
wired_devil
So, what back-end deepstream uses?

------
stevenwiles
ROFL totes awks. Upvote.

------
caub
meteor is a non-sense (but well I'd say rails too, and php shits too)

