
AngularJS and MongoDB: Goodbye middle tier? - mkj6
http://www.codebulb.ch/2015/05/angularjs-mongodb-goodbye-middle-tier-part-1.html
======
al2o3cr
"The example application proved nonetheless that building an application
without middle tier, based on AngularJS + MongoDB, is possible and very
straightforward"

Making the minimal featureset in the article happen seems like a necessary but
not sufficient condition to demonstrate that this technique is
"straightforward". Certainly, if implementing that app _isn 't_
straightforward then anything more complicated is doomed - but reading through
the RESTHeart docs does not fill me with confidence that things of realistic
complexity will be straightforward.

For instance, the RESTHeart "security" layer offers your choice of two
different not-remotely-production-ready "toy" identity managers; one that
works from a file of usernames & passwords, and one that uses a Mongo
collection of usernames and UNHASHED CLEARTEXT PASSWORDS. If you want
something better? Well fire up the ol' Java IDE...

I'd also quibble with the entire premise - RESTHeart _is_ a middle tier. It's
one that depends on YAML configuration rather than boilerplate code to
accomplish the features used in the article, but it's still a Java app that
deploys separately from Mongo.

------
mcorrand
For really small projects, a proper backend is not always necessary and
talking directly to the db can speed up development. I wouldn't dare do that
for anything serious though.

Couchdb is also a really nice way to do this, since it provides you with an
extensive (an extensible) rest api out of the box, serves your site and even
gets you a nice heroku like deployment workflow with the Couchapp project
([https://github.com/couchapp/couchapp](https://github.com/couchapp/couchapp)).
Sticking it behind varnish is really easy too.

~~~
eddieroger
I prototyped something exactly that way, including using Couch. It was really
great, and quick as you describe, but ultimately still required a proper
middle tier since the gap between a prototype and something deployable is
often a lot bigger than one realized, and I ended up having to do a lot of
work to get one situated in the middle. Though that ended up being an
enterprise app, which adds complexity.

~~~
mcorrand
Yep, enterprise apps definitely fall under the "serious" umbrella :).

If a middle tier is a foreseeable requirement then this architecture does lose
a lot of its charm.

I do think there has to be a way to easily strangle out the prototype but I
haven't done much thinking about that yet. Maybe start reading from a pouchdb
instance and proxy writes through a middle tier?

------
languagehacker
There are a bunch of easy technical critiques on this blog post. Here's a
pragmatic one: name me a REST API in a real-world piece of software that
doesn't have at least one chunk of special product-driven logic in it -- one
with customers, I'm saying.

As soon as you need to own even the smallest bit of backend logic, assuming
you're using a framework where everything else is done for you, you've cargo-
culted your way into trying to shoehorn the most degenerate case for a problem
into a generalized framework.

Like, god forbid you want your backend to talk to another internal service. Or
use third-party auth for managing access to privileged data. We should
definitely just send that to the client and let JavaScript sort that one out.
Love that idea.

Anyhow, this is a blog post that doesn't really do anything new, but presents
it in a way that claims it's evidence that something that a lot of people
stake their careers on isn't necessary. I'm happy to dismiss it in kind.

------
collyw
"I chose MongoDB because it’s considered by far the most widespread “NoSQL”
databases at the moment."

Pretty poor reason for choosing something.

~~~
danneu
I'd rather use the technically good-enough solution with a large ecosystem
than the technically perfect solution without one.

~~~
collyw
I agree with that but my point still stands.

------
blazespin
Well, at the end of the day you always need server side biz logic, I'm afraid!

Still, stored routines in a cloud DB might be more interesting than a full
blown middle tier.

The biggest problem with cloud DBs I find actually isn't so much their
architecture, but rather the fuzzy rules around charging access to them.

~~~
frik
> stored routines in a cloud DB

Application code in stored procedures? Is this still a thing? SQL2003 standard
was completely into it with Java as stored procedures and XML, etc. - but
wasn't that just an enterprise fade with big expensive enterprise databases
like Orcale/DB2/MSSQL?

It introduces a lot of headache if you update your code often - it's already
hard enough with schema changes, especially if you would like to be able to
roll back faulty updates. Normal code is maintained a source code repository
(GIT/SVN), it can be edited, diffed and debugged using a common IDE.

~~~
gaius
In what way aren't stored procedures "normal code"? Are you claiming Git can't
handle SQL files? Or that they can't be tested? Or there are no debuggers or
IDEs?

Here's a clue, a serious project will go through a dozen languages before it
changes its database. You can reimplement your business logic that many times,
or do it once, properly.

~~~
frik
What I tried to point out it complicates the schema-update step a lot. Lot's
code as stored procedures was counter productive at least in my experience.
Several blog posts (post mortems) mention they avoid stored procedures as much
as possible. I would debate that a "serious project" changes the code language
at all. Even the old rusty SAP only switched from ASM to C and ABAP and
reverted their Java misadventure. And Microsoft's products are still 90+% ASM,
C and C++ code

------
gaius
Back in the early 90s we called this "client-server", it was all the rage.

But the whole world moved onto to 3-tier for a reason.

~~~
topspin
This is correct, but ambiguous. What, exactly, was the reason?

The 90's client-server model involved fragile, proprietary stacks of non-
portable client software and proprietary protocols. That model would have you
"install" Google, Facebook and Amazon as separate applications. Ironically
this has reappeared as "apps" on portable systems; it seems we've figured out
how to make this work in constrained environments.

I have been solving some internal admin problems with a "two-tier" framework;
ng-admin + postgrest. The business logic lives in PostgreSQL stored procedures
and triggers. Effectively the middle tier has merged with the database so a
big moving part has been elided from the stack. One nice benefit is that the
cost paid to implement business logic produces a database model, not an
arbitrary accumulation of inscrutable middle tier `behavior.' The REST API
simply reflects -- and is always in perfect alignment with -- the database
model.

------
SonicSoul
how do you implement any sort of nontrivial authorization scheme w/out middle
tier? how can you share any code between different UI platforms? I also don't
like exposing data layer directly to the client. *or worse yet storing
business logic in the data layer

------
pmontra
If you absolutely trust the db clients not to mess with data, then you can do
this. Unfortunately it's usually not the case. Think about HN done completely
client side. Everybody would have 1 million points ;-)

That's why we still have that middle tier in our architectures.

------
trjordan
This means every backend deploy is a data migration. In my experience, that's
the only kind of difficult / scary deploy, and I'd rather not do more of
those.

------
bdcravens
If you app just displays data, sure. However, for more than that, it's a
question based on how much of your business logic you are willing to
essentially open source.

------
sktrdie
With things like Parse.com or Firebase we barely have to maintain or write any
code for the backend. So I would go as far as even saying "Goodbye backend
tier".

------
djmashko2
If you want to make an app with Angular and MongoDB with minimal code, I think
Angular-Meteor is one of the top choices! [http://www.angular-
meteor.com/](http://www.angular-meteor.com/)

This is one of the places where Meteor really shines, and it will also handle
building your code, deployment, realtime streaming, etc.

[disclaimer: I work at Meteor]

------
codingdave
It has always been possible to do without a middle tier. At the extreme,
vanilla JS can read/write directly to S3, and you don't even need a server or
a front-end framework of any kind. Not that you would want to.

The more interesting question is when would/could you actually do that, and
still have a fully function non-trivial app?

------
thefastlane
i'm admittedly not a big web dev, but as a side question: how does the
Mongo+RestHeart stack in the article compare to something like Meteor (which
also works well with Mongo)? when would you want to use one or the other?

~~~
imslavko
The point the article is trying to make is that their application has so
little server-side business logic, they can avoid it all together and not
write any server-side code.

Meteor, despite its ease of syncing subsets of data to users, gives you full
control to execute RPCs and run custom logic, talk to other backends, send
emails, etc.

------
itaysk
When prototyping I often start this way (client-datastore) but the first thing
that forces me to add a middle tier is authentication\authorization or
protecting the API for any reason.

------
mderazon
I don't get it. How do you handle authentication to the db without exposing
credentials on the client ?

------
rwbg
hood.ie looks like a much better backend for these scenarios

