This right here seems like the best trade off between accounting for technical debt in the future and having quick development in the early stages of a business/startup.
Koa is the successor of Express, written by Express creator, TJ. I like it because generator workflow makes writing apps better since we can yield promises. Code is much cleaner.
app.get('/', function * () {
this.body = yield User.all()
})
vs
app.get('/', function (req, res) {
User.all(function (err, users) {
if (err) throw err
res.end(users)
})
})
You can use promises in Express just fine, though. Especially with `express-promise-router`. Not really fair to compare it to nodeback code in Express :)
Inertia aka traction is very powerful in tech. Consider that all these negative articles do not percolate to various semi-isolated communities and groups.
There seem to be a large number of people who came into the tech-startup industry through programming a bit of Javascript, maybe from a web design background, who never had a formal education in computer science, who suddenly found out that they could write 'full' web apps in Javascript, and they could query a database in Javascript, but never learnt enough to know why this is a bad idea.
I'm not saying this is all bad, or that all Node devs are bad at all. Node is a good tool for a certain set of problems, and there are some excellent tools in the ecosystem and some great devs. But I think it is the easiest ecosystem to be a terrible developer in, and still get stuff working.
What does Mongo have to do with Javascript, and why is querying a DB with javascript a bad idea? What language you query a DB in should have no impact.
While I agree with most of your assessment, this is one bit I very much disagree with:
> But I think it is the easiest ecosystem to be a terrible developer in, and still get stuff working.
That honour would go to PHP, as far as I'm concerned. JS has many more fail-hard scenarios, and if you don't adapt your attitude to learn about things before using them, you're very quickly going to run into brick walls due to the entire callback thing.
Neither really has anything to do with MongoDB either - there's nothing inherently JS-y about MongoDB (JSON isn't JS), it just happens to have picked up a lot of traction around those parts.
To the comments that pointed out that JS and MongoDB aren't related, I'd argue they are, if only because the communities have related them.
The "MEAN" stack exists, MongoDB is popular in the JS community, and I feel they both exhibit many of the same hints of a fundamental lack of understanding about tools from a significant number of users.
As I said, there are great JS devs, and I'm sure there are some people using MongoDB for the 'right' things, but I don't think it's the majority.
Seems like you are saying Node is the new PHP or Ruby/Rails. It definitely has the most traction/gains so it has many experienced but also many newer devs.
Having read https://gist.github.com/mapopa/3619146, I'm not eager to trust the judgment of a team who was ever willing to handle users' data so recklessly. Same reason I avoid MySQL when I can.
The authors of the new storage layer mentioned in the GP are the team that originally wrote BerkeleyDB, which has been used for misson critical workloads for decades. One of the authors actually invented Serializable Snapshot Isolation (SSI), the concurrency control mechanism used in Postgres. If you don't trust them to handle your data, I don't really know who you should trust.
For quite a long time, mongodb defaulted to buffering writes (presumably to win benchmarks) and dropping errors on the floor. Storage is not the only layer at which their dangerously poor judgment could screw me and my users.
My only experience with DBs has been MS SQL, MySQL and PostgreSQL. I've always been intrigued with CouchDB. How friendly is CouchDB/PouchDB to someone from a SQL background?
CouchDB doesn't have a SQL like query language, and all acces is via http. Couchbase is higher performance with a binary protocol and autoscale features. So they are very different but they have in common that you store Json and then decide how to query it later.
You know why many SQL databases use a lot of RAM? Because it improves their performance. They don't require the RAM, they just use it when it's available. Would you rather that it uses your free RAM to speed up your database operations, or to just have it sit idle doing nothing?
As for not being "the only choice" - while technically correct, this is very misleading. SQL databases and schemaless/document stores are _not interchangeable_. They are used for different usecases with different data models and different integrity requirements.
MongoDB is a special one entirely - even for a schemaless document store, it's just very poorly designed and maintained. Use any of the many other such databases - which gained a reputation by actually working well in production, rather than its developers organizing lots of hackathons as a marketing stunt.
1. SQLite isn't heavy. There are probably even lighter-weight relational solutions, but I haven't needed one, so I haven't looked.
2. Even among non-relational document storage solutions, Mongo has a poor reputation. As someone else says elsewhere in the comments, it's hard to trust a team that let so many ridiculously dangerous bugs (and a basically unreliable design) out into production for so long.
No SQLite isn't heavy but I hope you mean for use in development only.
The issue isn't MongoDB is bad and relational DBs are awesome. The real issue is new developers being taught that Mongo and NoSQL in general are the databases you should be using with Node. The problem secondary to that is devs not knowing when each is appropriate.
It's actually commonly used in production for certain types of databases. SQLite is not a replacement for something such as postgresql but it certainly has it's use cases.
The use case for SQLite isn't high traffic public facing webpages. Here is their own list of 'famous' users: https://www.sqlite.org/famous.html
Every iPhone, and Android phone have SQLite running on them, which easily makes it the most used production database. It's use case is typically very low traffic websites or as client side storage.
Maybe I'm missing something but is Mongo in use on the client side in that same way? If not then SQLlite is being shoehorned into the discussion and the context in which production was used should be clear. I feel like people are trying to be technically right instead of following the actual discussion. I never meant client side software and definitely didn't mean someone's micro traffic blog, where a toy database could be used.
It is interesting how much penetration SQLlite has on the client, though.
At any rate, I know better than to not be extremely specific so I brought this on myself.
It seems like there have just been some assumptions going both ways.
This all started when someone trashed RDBMS for being "heavy", implying that Mongo is good because it's light.
Why would you care how heavy a DB is if it's not on the client side? The kind of memory and storage you need for even the heaviest popular RDBMS (MySQL?) is still low enough that's nearly free to create a small app.
A word of advice on passport. Don't just throw it in there and not learn anything about it. It's a really crafty middleware/library that is intended to be customized/extended. If you write your own strategies (after looking up the mainstream ones for reference) it'll give you a lot more power in terms of you authentication/authorization schemes.
I think that can be said about most products of scaffolds. If you intend to use this you should learn at least a little about node/express/jade/mongo/bootstrap as well. I feel a lot of people don't I know I didn't when I started web dev (I'm looking at you RoR).
I'm trying to remember the WTF moment I had with working with MongoDB, there were a few. I think it was not being able to do an atomic create or update operation across a collection of documents.
- Demo: https://koa-skeleton.danneu.com/
- Source: https://github.com/danneu/koa-skeleton