Dramatis Personae
PROGRAMMER, programmer
HIPSTER, hipster
* * *
ACT I
Small room. There are a table with paper stacks, opened "Perrier" bottle, two huge monitors and a programmer sitting behind. Programmer reads papers, looks on first monitor, then on second and typing something. From time to time he says "damn idiots". Number of "damn idiots" is divided equally between papers, first and second monitor.
Door opens loudly
PROGRAMMER: Who's there?
Hipster runs into waving his hands
HIPSTER: Framework! New awesome framework! Just look, it's awesome! Just look!
Programmer looks into hipster's iPad
@moccachino.render()
helloWorld({
view: "myProject.sample.view.Hello",
div: "myContainer",
data: {
message: "Hello World!"
}
});
PROGRAMMER: Damn idiots.
Exeunt.
(sorry for my English)
"Remove everything that has no relevance to the story. If you say in the first chapter that there is a bottle of Perrier on the table, in the second or third chapter it absolutely must land on a hipster's head. If it's not going to be smashed, it shouldn't be sitting there."
And perhaps the moral of the play is yet another variant of Chekhov's gun, but this one would be "Chekhov's framework"!
1. Why not just creating yeoman generator?
2. Don't you think it is too opinionated and inflexible to be useful?
1: https://github.com/Hashnode/mern-cli/blob/master/lib/main.js
That being said why Mongodb? NoSql are advantageous for write speeds, which as far as I know isn't particularly important for new applications. I understand that you want "javascript everywhere" but is that really worth the cost of losing the speedy and convenient join statements? I think postgres might have been a better choice.
"You can always replace Mongo with another DB like RethinkDB, CouchDB or something else you like. :)" What about SQL??!?!
(1) Node sprung up at the exact same time that NoSQL was in it's "fad" phase (which had much to do with fighting the now-mostly-solved scaling challenges of the SQL databases of the time). Both caught on with people who liked trying the hot new thing in 2010.
(2) There's definitely a bit more impedance mismatch when you're working with a SQL database from JS. If what you're trying to do is persist a blob of JSON, a NoSQL object/document store works at that level, whereas a SQL database requires thought and planning.
This is not to say that I prefer NoSQL, or that these are reasons why someone starting something now should choose NoSQL, but they do jump out to me as why backend JS dev has been a bit more NoSQL-happy over the years.
Reason: real-world data is almost never relational by nature, and you never really need ACID (even for financial data you can find a subset of ACID that's appropriate for you use case and complies with your regulations, and tweak a nosql solution to achieve it) and any relational model of data will be "awkward" in one way or another. Trying to get a more natural data model, it's always a question of either (1) storing graphs in a tree db (read "document db") or (2) trees in a graph db (no good open-source and easily scalable graph dbs around, too much developer inertia). Couple (1) > (2) for now, with the fact that write performance is more important than versioning for most (mostly because "naive" versioning at "big data scales" takes too much space), hence CouchDB < MongoDB and also "column dbs" being really odd for most general use cases and "nosql document dbs" remain the only sensitive choice for most projects.
I've finally seen the light and stopped recommending Postgres over Mongo to people :)
Rethink is probably a better idea. And there's also Arango. And I happen to love Neo4j. But Mongo is "good enough" for most, hence the obvious choice for a general purpose web framework.
Please don't. Your comment becomes much better if you simply take out that rude bit.
I had the feeling that data-models of document stores like MongoDB often only fit one use-case and fail after that.
A blog, for example.
You have Article and Comment and when using a document store, it comes naturally to embed Comment in Article, because, well the first thing you need is to display comments below articles.
Then you want to show the comments of a user, but they are stored inside the articles...
If you had a relational data-store the way to retrieve the data for both cases would be the same mechanism, a join.
Edit: At the very least Dan Abramov (Redux creator) is ok with universal [2]
[1] https://medium.com/@mjackson/universal-javascript-4761051b7a...
[2] https://github.com/gaearon/react-redux-universal-hot-example
It's still JavaScript, but how you design/write it is fundamentally different when you're writing for both the client and server.
From googling, they appear to be JS code that can run client and server-side? Not what I would have guessed!
> being of identical or similar form, shape, or structure
I call it fronty-backy-samey-samey and everyone knows what I'm talking about.
To me the word makes me imagine a web application that can parse its own rendered HTML and get back the application state. Which sounds kind of interesting...
SPAs are (relatively) slow to load. To improve perceived performance, the view requested is prerendered on the server with the ability to capture user input. The user sees a fully functioning site while the app bootstraps in the background.
Once the app is finished bootstrapping, the user inputs are replayed on the actual app.
This fixes the problem of poor perceived initial load times that come with SPAs. Once the app is bootstrapped everything is fast/snappy as one would expect with a SPA, incl no page refreshing between URIs.
Isomorphic React is already supported. Isomorphic Angular2 (ie Angular Universal) is in the works. I don't know about Ember but I'd assume they already support it.
…also known as 'universal apps' nowadays
(see https://medium.com/@mjackson/universal-javascript-4761051b7a...)
Overall the presentation of your system is great. However, the documentation needs work, particularly on how to create a complete mini-MVP. Examples, even if dinky, help a lot. Many developers will just download an example and start messing around and see how it feels.
An important note on app structure:
I noticed how the approach you take involves maintaining lot of file structure, all reflecting the underlying conceptual framework. IMO, even when generated, complex file structures draw away from our developer productivity. Think about "flattening" some of that. Think about organizing the system around the aspects of the implementation, even if it is at the cost of (for lack of a better word) consistency.
The framework should serve the primary concerns in the mind of the developer: user, group, post, item, etc. rather than the primary concerns in the mind of the framework maker :)
Hope this helps, and good luck in Dodge City!
The whole point is to make it easy to work with this full stack framework, so, that means to have excellent docs and StackOverflow support.
git checkout-index -f -a --prefix=/path/to/folder/
My 2 cents, I've been enjoying using websockets and redis with this stack. And +1 for considering the term Universal in the tagline.
That's been around for a while: http://ember-cli.com/user-guide/#using-ember-cli
SQL can be even more of a pain because you'll need additional checks to handle the SQL server's particular blend of error handling if/when something goes wrong.
In both SQL and NoSQL, any decent ORM should provide models, validations, sane error handling, and constraint checks so none of those really matter.
Unless, for whatever reason the business logic is defined in SQL SPROCS. Then, good luck if/when they don't work properly.
It's not for every project, but quite nice for prototyping.
MongoDB is far from "simple to work with". This is 100% marketing bullshit (along with dubious claims like it being "fast" when it never has been), trotted out by MongoDB's marketing department. Let's not forget that it has always been a commercial project.
EDIT: And to clarify, relational databases and document stores are not interchangeable. You need to pick the one that reflects your data model most accurately.
Usually that's going to be "relational", sometimes it will be "documents" - but even if it is, there are better options than MongoDB.
JSON is an entirely separate language from JavaScript, and it can be used from just about any language. This "convert a native object into the query format" thing is also literally what almost every database driver in almost every language does.
This has precisely zero to do with either MongoDB or JavaScript.
You still have a server to run, auth to check, etc...
Here's a real database with no configuration, no nothing, actual real plug-and-play:
Most people are not building Big Data systems.
Every major database does. This is in no way exclusive to MongoDB.
It has very good integration with Hadoop, Spark etc.
I can't understand how to get a development team starting with something like this to something like a microservices API without a complete/major rewrite or painful decoupling/transition sprint(s). Or am I missing something here?
Edit: I forgot that isomorphic is a trigger word. Took that out.
vs
https://en.wikipedia.org/wiki/Linguistic_description
You might dislike it but it's become common usage in the js community so by any reasonable non-prescriptive definition of 'means' it 'means' what this author says.