AngularJS and MongoDB: Goodbye middle tier?
codebulb.ch
codebulb.ch
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.
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). Sticking it behind varnish is really easy too.
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?
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.
Pretty poor reason for choosing something.
If you're just trying to learn stuff, there are more people to help you out and more answers on Stack Overflow.
Not advocating Mongo here, just saying that adoption is not an irrational reason. I have mostly seen this with Java, when people tell me: We chose Java, because that's what they teach at universities and this is what developers know.
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.
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.
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.
But the whole world moved onto to 3-tier for a 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.
That's why we still have that middle tier in our architectures.
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]
The more interesting question is when would/could you actually do that, and still have a fully function non-trivial app?
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.