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.
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.
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!
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
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?
"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.
> 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...)
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.
It's tough for me to say "finally killed and buried" when I have a couple dozen colleagues being wonderfully productive with SQL as one of their primary tools. Application developers and analysts don't need to use the same tool, though.
On the client you wouldn't use `fs` module, but on the server you wouldn't use jQuery unless you were manipulating the dom through scraping with Cheerios.
"There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."
That's why I suggest it's good for prototyping, maybe it will work for some projects long-term, but I don't think it's the norm as mongoDb would suggest.
However, most prototypes don't end up as successes, so that's where I figure it's worth the switching cost once a go-nogo decision is made.
It's a completely fallacious argument. Using MongoDB doesn't save you time, it just shifts the effort towards a later point, where it will require several times as much effort to fix shit, which may not even succeed and you may end up with corrupted data.
It's really not worth it.
Sample code is documentation. For a lot of users, the sample code is the only documentation they're going to read when they're starting out. If you consider that, doing it the right way in your sample code is critical.
Further, it feels a lot like false advertising. If input validation is awkward in your framework, and I don't discover that until later on down the road, I'm probably going to feel deceived. If the "demo code" is a screenful of code, and doing the same activity but doing it in a secure way (i.e. no XSS, etc) results in 10 screenfuls of code, I'm going to feel that either: a) the author of the framework doesn't know what they're doing, or b) they were trying to make the framework look super minimal, when it actually requires the same amount of boilerplate junk that everyone else requires. Either way, I'm not going to be super pleased. Just show it the right way upfront!
Isomorphic means that the same code can be used to "pre-render" an app on the server and to interactively run the app on the client, preferably without losing input state if the client-side execution is delayed (i.e. not throwing away the rendered content but attaching to it).
More generally it means that the code wraps any underlying APIs to make it behave similarly (but not necessarily identically) in node and the browser. Like isomorphic-fetch, which uses a polyfill (i.e. a fallback implementation in the absence of a native API) for the Fetch API in the browser or a node-based implementation in node.
The reason some people prefer the term isomorphic over universal is that isomorphic has no conflicting definition in the context of web apps. Universal on the other hand is extremely vague and ambiguous (ranging from "takes accessibility into account" to "works with different third party APIs" to "language independent").
The reason some people prefer the term universal over isomorphic is that isomorphic as a scientific term has unrelated meanings in mathematics, chemistry and other fields which can be domains for web apps.
Of course the real joke is that the definition is only about node and browsers, making no claim whatsoever about "all JS environments" or even "most". This is one of the reasons I personally don't like the term "universal": it implies a scope that simply isn't intended by most projects the term would be applied to. Something that only works in Edge and Node 5 might be "universal" but it isn't universal at all.
And the original use was in Philology[0]. Just because a word has two different meanings in two different contexts doesn't means it's wrong. I'm certainly glad the linguists didn't get up in arms when the mathematicians gave the 'wrong connotation' to isomorphism.
[0] - https://books.google.com/books?id=hZpeAAAAcAAJ&pg=PA711&lpg=...
By the way, for the broader point about language mutation, and prescriptivism vs descriptivism, I think there's a common stance against prescriptivism that also seems to rule out any negative opinion about language change—to which I say, hey, negative opinions are part of the whole mess too, even from a descriptivist standpoint. But this is a derail already; sorry.
"<script>" might be a legitimate input.
If you escape one step further you'll lose formatting or the message, so sanitisation is important too, it is reductive to say "always escape never sanitise".
Whether it looks the same is irrelevant. It doesn't even have the same syntax rules. For example, this is valid JavaScript:
{
one: "two",
three: undefined
}
> don't see how it's the same as converting for example PHP to MySQL where I'm bound by a schema which looks nothing like my data structure in PHP
And in 99% of cases, this is a feature, because you can't represent most data as a flat list of nested objects. See also this article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
Aside from that, if you want a native nested representation of data in your database, so including relations, you use an ORM. For example, in PHP with MySQL, you might use Eloquent.
How data is represented in your application and how it's represented in the database, are two entirely different things. There's no advantage to be gained from trying to make them the same thing - that's the concern of the database abstraction that you choose to use.
http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...
Additionally, user data isn't the only data that needs to be validated. The vast majority of our data is generated by the program itself, and schemaless databases have given us endless headaches with this.
Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing.
Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client.
Is JS is used on both the server and client, it makes a lot more sense to have ORM models that act as the single source of truth for structure (ie model/schema), condtraints, testing, and validations.
Issues with unstructured data come either from laziness (ie not using schemas in production code) or mismanagement (ie not handling migrations properly between schema changes).
Having the ability to use completely schema-free, unstructured data doesn't mean schema/validations should be ignored altogether.
You wouldn't blame the gun if you shot yourself in the foot, would you?
There may be more than one client connecting to the database at the same time (or even internal inconsistencies within the same process), and the only way to prevent data inconsistencies is to hand the final responsibility of validation to the thing that is actually storing the data, ie. the database.
In the end, your database is the single source of truth, as it is the only part of your architecture that is technically capable of doing so. Client-side validation and server-side validation (in the application) are niceties for UX purposes, but do not and cannot replace database constraints.
If it was unreasonably easy to do so, then yes. This is why there are gun safeties. The phrase "hairpin trigger" or "hair trigger" derives from guns with light triggers that made a premature or accidental discharge too easy.
"A poor workman blames his tools" only works if you have real tools. It's OK to blame tools when you're forced to use a twig as a hammer.