"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.
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). Sticking it behind varnish is really easy too.
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.
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?
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.
For a side project, there are advantages to choosing something popular. If you're building a side project to bulk up your resume, choosing something popular can help you land a job (as there are more available).
If you're just trying to learn stuff, there are more people to help you out and more answers on Stack Overflow.
Widespread usually means a lot of people are familiar with it and since the community is large, problems should arise and be fixed quickly - in the best case.
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.
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.
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.
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
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.
One MS place I worked were adamant that 3 tier meant physical separation as well; e.g. frontend servers, BL/middle-tier servers and database and duct-tape everything together with webservices or binary serialization. Thats when you know you are /really/ wearing your big boy pants to work.
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
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.
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.
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.
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".
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/
This is one of the places where Meteor really shines, and it will also handle building your code, deployment, realtime streaming, etc.
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?
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?
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.
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.
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.