21–30 of 35 posts
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.
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.
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." 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.
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]
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." Pretty poor reason for choosing something.
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.
"I chose MongoDB because it’s considered by far the most widespread “NoSQL” databases at the moment." Pretty poor reason for choosing something.
I'd rather use the technically good-enough solution with a large ecosystem than the technically perfect solution without one.
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.