MEAN Vs. LAMP: Finding the Right Fit For Your Next Project 175
snydeq writes: LAMP diehards take note: The flexible simplicity of MongoDB, ExpressJS, AngularJS, and Node.js is no joke and could very well be a worthwhile stack for your next programming project, writes InfoWorld's Peter Wayner. "It was only a few years ago that MongoDB, Express.js, AngularJS, and Node.js were raising eyebrows on their own. Now they've grown up and ganged up, and together they're doing serious work, poaching no small number of developers from the vast LAMP camp. But how exactly does this newfangled MEAN thing stack up against LAMP? When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?"
The Fuck? (Score:5, Insightful)
>This isn't a problem if every single entry fits into exactly the same format, but how often is the world that generous?
> What if two people share the same address but not the same account?
You dont make it a unique field?
> What if you want to have three lines to the address instead of two?
You have an empty field?
> Who hasn’t tried to fix a relational database by shoehorning too much data into a single column? Or else you end up adding yet another column, and the table grows unbounded.
Yeah, I cant read this crap considering the very next section is 'Disk space is cheap'. If it's cheap, who cares about 1 extra field in the database.
Remember guys MongoDB is webscale
Re: (Score:2, Insightful)
Might as well just call this place, Digg 3.0 - Getting Shittier All the Time.
Re:The Fuck? (Score:5, Insightful)
It's almost as if the writer doesn't understand what a relational database is.
Re: (Score:3)
...at all.
But you know, it's totally cool to run your tiny startup's auth DB on its own multi-box sharded cluster... n' stuff. Bragging rights and all that.
Re:The Fuck? (Score:5, Insightful)
And the author hasn't looked at a relation database in the last few years, either. PostgreSQL, Oracle, MySQL, and I'm sure the other big ones all have JSON (or similar) column types now that let you attach semi-structured elements to your records. You get all the benefits of a RDBMs (ACID, referential integrity, 40 years of history) _and_ all the benefits of NoSQL.
Seriously, there's no good reason not to start with PostgreSQL and only add MongoDB if you really have a good use case for it (you know, you suddenly need to be Web Scale). Personally (and professionally), I use both, with PostgreSQL as the main DB for everything and MongoDB for read-only collections of indexed data.
My challenge to devs out there: spend the hour it takes to learn SQL and understand what you can actually do with it. And, stop pretending that an RDBMS won't scale to meet your needs (spoiler alert: it will).
-Chris
Re:The Fuck? (Score:5, Informative)
I know SQL pretty well. I agree with you it handles most stuff. That doesn't mean it handles everything.
SQL engines are often slower.
SQL engines have problems with massive parallelism (i.e often at around 12 CPUs you stop gaining much at all by adding addition CPU).
SQL engines have problems with complex in document (i.e. in blob) searches
etc...
Re:The Fuck? (Score:5, Insightful)
Not to be rude, but what the hell are you talking about?
SQL engines are often slower than what? In what scenario? Operating on what hypothetical database schema with how many records spread across how many tables?
SQL engines have problems with massive parallelism? Why? Which ones?
How well do you *really* know SQL in general and the capabilities of different database engines in particular? I suspect you may know less than some people who know SQL *really* well (as opposed to *pretty* well).
I apologize for the tenor of this post, but that portion off the article was ridiculous, and thus far all of the comments in support of it have demonstrated a similar lack of familiarity with actual databases, their operation, or performance tuning.
Re: (Score:2)
Re: (Score:3, Funny)
Just an FYI, jbolden works for Microsoft. So his experience and comments would be related solely to SQLServer.
Re: (Score:2)
Just an FYI, jbolden works for Microsoft. So his experience and comments would be related solely to SQLServer.
jbolden appears to be a managing partner of his own consulting firm, and his linkedin resume not only doesn't mention Microsoft but it lists Oracle multiple times with no mention of MSSQL Server.
But that only makes his post even more confusing, since there are very few scenarios extreme enough that Oracle cannot handle the database workload as well as any NoSQL solution. Although there are many scenarios where a novice Oracle DBA could not get the same performance as a novice NoSQL DBA. But god help those n
Re:The Fuck? (Score:4, Informative)
You are correct, I've never worked for Microsoft I don't even sell much Microsoft. Mostly when I'm dealing with SQLServer datasets they have been no problem for RDBMS. My company has helped do connector work for Azure on Hadoop / SQLServer mixtures.
I suspect the reason AC thought I worked for Microsoft was I thought the Windows 8 (and early new interface for Office) migration program (i.e shift the x86 ecosystem) that Balmer / Office group was pushing made a lot of sense and defended it.
Oracle is excellent. Oracle has problems with massive parallelism though. The Oracle engine works well at 10 CPUs handling versatile workloads. It doesn't at 1000 CPUs focusing on one big table scan for one query.
If you aren't using relational you better be using old fashioned block type strategies (i.e. full table writes like you do in COBOL) or not be doing transaction processing at all. That's one of the things you are giving up when you go non-relational. Data changes become much trickier.
But that's not a problem for most NoSQL where you just write the data out, process it for X time and changes are handled via appends if at all. A good relational analogy to the append structure is how RDBMS handle materialized views and data changes.
Re:The Fuck? (Score:5, Informative)
Than engines designed for massive parallelism in dealing with workloads which can be effectually processed in parallel.
Generally NoSQL engines use schema on read techniques not schema on write. The table structure comes during the read. To get some sort of fair comparison something like a typical star schema with a much too large fact table (think billions or trillions of rows) and a half dozen dimension tables.
Or if you really want to make it worse. The same query where the table is getting 1m writes / second and you want an accurate stream.
Because SQL by its nature operates on the table not the individual rows. Older database technologies that were row oriented like what you see on a mainframe on in SaS work better when the ratio of table size to computation speed is low. Today because disk storage size per dollar has gone up so fast, we disk we face many of the same problems systems in the 1980s faced with tape.
And the next question is pretty much all of them. The big data SQL engines have the least problems though and via. their execution plans turning into map-reduces might present a viable long term solution.
Assume I don't know anything. Oracle, which has the best engine and SQL people on the planet has a guide for hybridization to handle things their engine can't handle well. IBM which probably comes in second and invented the relational database produces their own Hadoop / R to handle queries that DB2 (which is BTW far better than Oracle at stream) can't handle. Teradata's engine which was originally written specifically for larger amounts of data for a decade has had specific features of another subsystem to do enhanced big data, they also have guides for hybridization for things even their enhanced engine can't handle And Microsoft which writes the 3rd most popular engine has spent many millions on hybridization strategies. Enterprise DB (postgres) fully supports the IBM strategy.
I don't know anyone in the space who does agree with the /. "SQL can do everything" attitude.
The article was ridiculous I said as much in another response. However the comment I was responding to went much too far in the other direction. As for performance tuning -- performance tuning is designed to avoid full table scans and expensive joins. To goal of many hybridization strategies is to take a raw data flow and convert it into a relational ETL using a big data engine which can take advantage of indexing and a better execution plan. It doesn't do much good when the initial goal is to do a full table scan.
Re: (Score:2)
Ok, thanks for the clarification.
NoSQL scenarios being what they are, there are obviously cases when they make sense and have advantages in terms of performance, but it's not always a win, especially if you don't know what you're doing or why.
I don't know anyone who believes that SQL can do everything either, especially when dealing with extremely large datasets, but analytics and search on huge datasets are not the scenario that your typical dev who doesn't know whether or why to use LAMP or MEAN in the fi
Re: (Score:2)
I agree. I always start big data conversations with the "what query do you want to perform that doesn't work on RDBMS"? If they can't even name one then there is no reason to go big data. A dataset under a 100g, that isn't being read / destroyed quickly that can be structured consistently never needs big data. One of those 3 things has to not be true.
The problem on /. right now is that lots of the developers who are SQL
Re: (Score:2)
Re: (Score:2)
Absolutely true. SQL technology is much more mature. But just like SQL made sense in a world where non-SQL COBOL based systems were more mature for many client-server workloads, big data makes sense for non client server workloads of the kind that are more similar from a hardware standpoint to the old non-SQL workloads.
Re: (Score:3)
SQL engines are often slower.
Well, for queries on structured data, no, not often at all. Practically never if properly configured.
SQL engines have problems with massive parallelism (i.e often at around 12 CPUs you stop gaining much at all by adding addition CPU).
Maybe MySQL does, I don't know. PostgreSQL does not. And the big expensive proprietary brands certainly scale well.
SQL engines have problems with complex in document (i.e. in blob) searches
Finally, a kernel of truth. Of course blobs are often an excuse to be lazy and not figure out the actual structure of the data, but in cases where blobs are truly appropriate, there are better solutions than SQL, for the blob parts at least.
Re: (Score:2)
Why do the people who make those engines disagree with you and advocate hybrid strategies?
Enterprise DB which writes Postgres disagrees with you. That's one reason they have a practice around supporting IBM's big data platform and themselves author the Postgres Plus Connector for Hadoop.
Re: (Score:2)
Teradata, Vertica ... use hybridization and big data strategies inside their engines. They don't refute the point, they prove it.
Re: (Score:2)
And then what? How do you get them to work together? You could add a coordination system between them so you have a bunch of slaves nodes getting dispatches from the master node? Well to make that work you need to design your data to be partitioned and your workload to be able to be combined at the coordination level with little contact between the coordinator and the slave nodes. That's a big data engine.
Re:The Fuck? (Score:4, Informative)
The last few years in this case is more like the last decade. Before JSON, there were (and are) XML-typed columns, and any decent RDBMS will let you use XQuery or similar to query on them directly within your SQL query (and will use special indices to optimize such queries). SQL/XML spec, that standardizes this, was published in 2003. Oracle shipped preliminary support of the then-draft spec in 2002; Microsoft shipped it in SQL Server 2005 in, well, 2005; and Postgres shipped it in 8.3 in 2008.
Re:The Fuck? (Score:4, Insightful)
What's really concerning is that I've had "new school" web devs completely laugh at me when I suggest they ask their resident DBA questions about database performance, etc. Apparently, a DBA is just someone who makes images and restores backups now. "Hey guys, let's make a business that's completely reliant upon reliable data, and then completely ignore getting someone who's entire knowledge specialization is data management and arrangement... Yeah, fuck those dba guys..."
Re: (Score:2)
And the author hasn't looked at a relation database in the last few years, either. PostgreSQL, Oracle, MySQL, and I'm sure the other big ones all have JSON (or similar) column types now that let you attach semi-structured elements to your records. You get all the benefits of a RDBMs (ACID, referential integrity, 40 years of history) _and_ all the benefits of NoSQL.
Seriously, there's no good reason not to start with PostgreSQL and only add MongoDB if you really have a good use case for it (you know, you suddenly need to be Web Scale). Personally (and professionally), I use both, with PostgreSQL as the main DB for everything and MongoDB for read-only collections of indexed data.
My challenge to devs out there: spend the hour it takes to learn SQL and understand what you can actually do with it. And, stop pretending that an RDBMS won't scale to meet your needs (spoiler alert: it will).
-Chris
What JSON column types exist in MySQL? I know that MariaDB supports COLUMN_JSON() on dynamic columns for SELECT statements (but no way to insert JSON), but MySQL seems to have no native JSON support. Even the third-party components such as mysqljson only import and export JSON, there is no internal JSON nor dynamic column storage and the values are stored in native MySQL datatypes in predefined columns.
Even in MariaDB, WHEREing from a dynamic column means parsing the whole table's dynamic columns (i.e. no
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I am aware of those features but most applications that rely on relational databases use some kind of object relational mapping, I never looked into it bu how is the support of those features in that context?
Re: (Score:2)
Seriously, there's no good reason not to start with PostgreSQL and only add MongoDB...
Although I've never needed MongoDB myself, I can see situations where it would be appropriate. I see ***NO*** situations where the ass-backward inside-out semantic model of Node.js is actually appropriate. There are ways to scale to serving high activity loads (actually, higher than Node has any chance of serving), with obfuscating control flow and making it so godawful difficult to be sure that you've handled all combinations of normal completion and errors thrown.
Re:The Fuck? (Score:5, Funny)
I enjoyed this gem:
If you write code for Node and decide it’s better placed in AngularJS, you can move it over with ease, and it's almost certain to run the same way.
Yes, if there's one thing professional programmers (and their PHBs) love, it's code that's almost certain to work.
Variable Definitions (Score:2)
Yes, if there's one thing professional programmers (and their PHBs) love, it's code that's almost certain to work.
The reason that's OK for everyone is that it's also "Almost Certain" to work in the original place also...
It's just that each placement has different values and flavors of "Almost". :-)
Re: (Score:3)
Lack of Certainly.
That's a big one. Not just in that context. It's why I'll forever maintain that new exciting things are for playing and old and stable things are for work. When you already know the problems, risk, and challenges, you're better able to plan. When you pick from the latest headlines, you're almost guaranteed to pick a flash-in-the-pan technology that'll be dead and gone in a year or two.
Re: (Score:2)
Even *I* know that Node.js is a backend "engine"/"framework" and AngularJS is a front end technology.
So: you can not replace one of them with the other!
Re: (Score:2)
Field validation? You might arguably want some of the same code on both sides for more complex field validation, since client-side is more responsive.
Re: (Score:2)
That is not "replacing" ...
Re: (Score:2)
Original post:
If you write code for Node and decide it’s better placed in AngularJS, you can move it over with ease
You're right. That's not replacing. But code that works client-side could be moved server-side and vice-versa. And I gave an example of one case where that might happen. Or where the same code might be used in both places. I don't really know why you're in love with the fact that you used the word replacing, so I can't address it any more specifically.
Re: (Score:2)
Well, was it you, or wasn't it another parent who used it?
Using the phrase "you can replace node.js with AngularJS" implies you can replace the whole back end site framework with a whole front end site framework.
Obviously that makes no sense at all.
Putting client side verification code as a verbatim copy into the backend implies that you use the exact same JavaScript objects (at least with the same "hashes") on both sides, which you likely don't do. On the backend you have "objects" on the front end you hav
Re: (Score:2)
Re: (Score:2)
If the same code doesn't "run the same way" (by which I take it to mean produces the same output from the same input) in two different places, then I'd class that as not working.
Re: (Score:2)
Which category does the "why the hell does that even work" code fall into?
Re:The Fuck? (Score:5, Funny)
Ruby
Re:The Fuck? (Score:4, Funny)
"MongoDB is webscale"
For those that have not seen it yet: https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
I hadn't seen it. I thank you.
Re: (Score:2)
Obligatory:
https://pbs.twimg.com/media/BN... [twimg.com]
From:
http://www.reddit.com/r/Progra... [reddit.com]
Re: (Score:2)
MEAN may have its place, but those duplicate fields implies not just additional disk space, but more data that has to be backed up, more data that can be hacked, more data that can get corrupted (what happens if two identical fields wind up with different values... what FirstName gets precedence), more data the backend RDBMS has to chug through.
For smallish tasks, this isn't a big deal, since a small Linode VM or whatnot can do the tasks. However, this can impose a performance and space penalty that can be
Re:The Fuck? (Score:4, Funny)
Hush, the 20 year olds think they invented something.
“When I was a boy of 14, my father was so ignorant I could hardly stand to have the old man around. But when I got to be 21, I was astonished at how much the old man had learned in seven years.”
Once you get a B.S., you think you know everything. Once you get an M.S., you realize you know nothing. Once you get a Ph.D., you realize no one knows anything!
Re: (Score:2)
/Oblg. but MongoDB has webscale [youtube.com]
Re: (Score:2)
Having used Mongo and Node at "scale"
interesting. care to elaborate?
I've concluded that neither should be used in a production environment unless you know *exactly* what you're doing
isn't that true for any platform. and, do you really use stuff in production without knowing "exactly" what you are doing?
Mongo is *really* hard to scale well, as you need *lots* of nodes to shard your data across to get good performance out of large data sets (ok small single server stuff is fine).
adding nodes to shard data seems like a straightforward scaling strategy. how does this not scale well? what problems are you having?
Node stuff (which includes express) requires a bunch of backend infrastructure and training devs to write multi-host deployments which can be hard.
how are multi-host deployments exclusive to 'node stuff'? don't you need infrastructure and trained devs for any deployment? what are you comparing?
The real problem is people read "web scale" and believe their mantra about scalability, when the same problems exist with all other platforms, yet on their own they solve none of the problems. The devs I've met that are huge advocates seem to either ignore of not understand these problems.
They're just extra items to add to your tech catalogs which have benefits and drawbacks.... Just don't treat them as the only items! ;)
honestly, i find braindead hype as delusional as your reactionary attitude and
Re: (Score:2)
You obviously never had issues with MSSQL/Oracle then. A badly performing RDBMS is usually due to a bad DBA or a bad history. Oracle/MSSQL are simply a bit more forgiving as long as you keep throwing hardware and licenses at the issue.
If you look at MariaDB or even MySQL >4, a lot of the issues GP is complaining about have been resolved a long time ago. BDB/InnoDB have been available for a long time. And there is still no native multi-master PostgreSQL.
Great comparison (Score:5, Insightful)
Which is a better tool for outdoor work, a lawn mower or a snowblower?
Re:Great comparison (Score:5, Funny)
Your mama was a snowblower!
Re: (Score:2)
It depends if you're living under the pacific ocean or the atlantic ocean.
Re: (Score:2)
Which is a better tool for outdoor work, a lawn mower or a snowblower?
It depends if you're living under the pacific ocean or the atlantic ocean.
Under? Snorkel.
Re: (Score:2)
Well, then, you don't want a lawnmower or a snowblower. You want a soil aerator.
Obligatory Blazing Saddles Reference (Score:2)
Different types of terms (Score:5, Funny)
Never heard of "MEAN" before now, but that doesn't align with the term "LAMP" which describes the entire server/platform. "LAMP" includes the operating system (Linux) and web server (Apache) in the name https://en.wikipedia.org/wiki/... [wikipedia.org]
While MEAN does not https://en.wikipedia.org/wiki/... [wikipedia.org]
So would it be "LAMEAN" perhaps? :)
Re:Different types of terms (Score:5, Insightful)
I think the who problem with LAMP or MEAN is that it's trying to define one web stack. The world has moved on. Some companies deploy nginx now instead of apache or in combination with it. Netflix sends 33% of all Internet traffic on FreeBSD rather than Linux. I've seen so many people replace the P in LAMP to be python. We can't even agree on the P.
My current stack at work is FATAPJ - FreeBSD, Apache, Tomcat, AngularJS, PostgreSQL, Java
Re: (Score:2)
Agreed, we could make hundreds of different combinations of acronyms for different stuff! But I will say, your "FATAPJ" stack is a little hard to pronounce.... thus, you should change some components as soon as possible, preferably with another vowel near the end :)
Re:Different types of terms (Score:5, Funny)
As long as they don't replace it with Erlang, because then it would just be LAME.
Re: (Score:3, Funny)
Well, at least it isn't FreeBSD, Apache, Tomcat, AngularJS, Lua, Bash, Emacs, Ruby, and TypeScript.
Re: (Score:2)
So would it be "LAMEAN" perhaps? :)
Pretty sure that this is a deliberate attempt to make the project have a more appealing name. LAMEAN is likely to be pronounced with a bad Spanish accent, "La MEAN," or pronounced as two words, "LAME AN." I can hear someone saying, "That project was LAME AN' just not worth it."
Re: (Score:2)
I think their idea may be that the OS is no longer relevant (you know, thanks to Docker or similar)?
BTW, the "A" in LAMP is allegedly to be replaced by the "N" (as in, node.js), which IMHO is cute, but damned sure not as flexible a solution that Apache, nginx, or even (*ducks*) Tomcat provides.
Re: (Score:2)
I think their idea may be that the OS is no longer relevant (you know, thanks to Docker or similar)?
yes, node is available on several platforms. :D)
(but docker is linux only for the time being
BTW, the "A" in LAMP is allegedly to be replaced by the "N"
actually, this whole silver bullet 'stack' approach is nonsense. back in the days of lamp there were far fewer options, there was also little expertise with 'modern' webapps and high availability, it could make sense branding something like 'lamp' and have it distributed to developers and almost preinstalled on private servers. those days are gone, today there are many tools you can combine in different ways to suit
Re: Different types of terms (Score:3)
Stupid buzzword acronyms aren't just for MBAs anymore.
Re:Different types of terms (Score:5, Funny)
Something other than Node is likely used for the static parts of a site or for caching. Apache or Nginx are likely candidates. There are endless stack names, and they can be as silly as we want and someone could still build something useful on them. LAMP got coined because the stack was so popular together, with the 'P' being /P(erl|HP|ython)/ in many camps. That doesn't mean they'll all catch on as common, popular stacks.
Some people use BAPP -- BSD, Apache, PostgreSQL, Perl/Python/PHP. Some people use specifically FreeBSD: FAPP. Some people use FreeBSD, Apache, Perl, and SQLite...
Here are some other less common web stacks:
MongoDB, ExpressJS, Linux, AngularJS, NodeJS, Groovy, Erlang
MELANGE
Scala, Python, AngularJS, Zope
SPAZ
Clojure, Linux, Oracle DB, WebGL, Nginx
CLOWN
PostgreSQL, io.js, Scala, Solaris, Erlang, D
PISSED
SQLite, Ubuntu, C, korn shell, io.js, TCL
SUCKIT
Lighttpd, io.js, C, Kadmelia
LICK
Apache, Mumps, io.js, R, Ingres, Twitter API, Enterprise JavaBeans
AMIRITE
Re: (Score:3)
R, IIS, MongoDB, JQuery, Oracle, BigTable
That's what I most associate with Enterprise web development. Feel free to substitute IIS with Intercal.
Angular (Score:5, Interesting)
I can't comment on the other technologies, but Angular has transformed how I build the interactive parts of web pages.
When you first approach Angular it seems like an over-engineered, incomprehensible edifice, and the tutorial throws you straight into writing your whole website as a single-page application. But once your realise that you can use a small lump of it on a single page to bind some UI elements to javascript state objects, you find yourself using it all the time even for small things. For me at least, it's as much a revelation as jquery was.
Re: (Score:2)
There are way smaller libraries that can bind UI to state. I use them because Angular is an over-engineered incomprehensible edifice if that's all you want to do. If I'd want something the size of Angular, I'd also expect something that actually tracks/updates state in the backend.
So much stupid (Score:5, Informative)
Among the great revelations of relational databases was the JOIN command. With JOIN, we could save disk space by removing repeated fields like city, state, and ZIP code. By storing this frequently accessed and repeated data in separate tables that can be included in future results through a JOIN, we keep our database tidy and our disks slim. But JOINs can be tricky for some and hard on RAM, and though it's still a good idea to isolate and access data in separate tables through JOINs, there's not as much need to save disk space now that disk drives are measured in multiple terabytes. The space is so cheap that some database designers end up denormalizing their data because the JOINs are too slow.
This is just so wrong. If you store, let's say, city/state/zip redundantly, then you run the risk of having the copies, that should be kept synchronized, diverge. This is especially true in the absence of all-or-none transactions. And not to mention the fact that having to update the "same" datum in multiple places is going to affect performance.
why would you ever? (Score:2, Insightful)
When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?
always
Move to App-Server. Try GARMS (Score:2)
The CGI model used in LAMP meant your front-end could scale indefinitely, but the backend (Database) had to deal with a connection create/teardown on each request, so databases where that was fast are what won that round (MySQL).
Now there's the App-Server model, which has some brittleness when people think they can save state locally, but they can't at scale (when you need more than one box). On the other hand, persistent and reused connections to backend resources mean faster TCP (already-warm). To scale t
Terrible arguments for Big Data (Score:2)
I'm a big data advocate. I like the idea of engines designed for unstructured data. But the two examples in the article barely even register as difficulties of relational databases, "What if two people share the same address but not the same account? What if you want to have three lines to the address instead of two? Who hasn’t tried to fix a relational database by shoehorning too much data into a single column? Or else you end up adding yet another column, and the table grows unbounded.".
As for his
Re: (Score:2)
Re: (Score:2)
Good comment. K/V can be potentially added to SQL.
Re: (Score:2)
The main reason is when the blow up in practice is sparse.
Say for example A has 1 million rows and 20 columns. B has 1 million rows and 20 columns. Column A1 is a link to rows in B. On average a value in A1 will have 3 corresponding rows in B. Pulls from A*B tend to be 5 rows or less. It is cheap to just pull the appropriate blocks from A and then the appropriate blocks from B. That's going to be much faster than denormalizing,
MongoDB? Thanks., I'll pass (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Not only because stuff like this, https://aphyr.com/posts/322-ca... [aphyr.com] , but also because MongoDB performance actually isn't that great. I do care about my data, and PostgreSQL is actually faster in some scenarios (eg. if you actually know what you're doing), so thanks, I'll pass. And Apache HTTPD? Who's still using that on new projects?
Curious, if not Apache httpd, then what?
Re: (Score:2)
Re: (Score:2)
Jepsen (Score:5, Interesting)
Remember folks, MongoDB has failed the Jepsen Test multiple times.
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads [aphyr.com]
Re: (Score:2)
Note (Score:2)
Just because you decide to use Node, doesn't mean there's any particular reason, why you should have to use Mongo and Angular. You might prefer Backbone and Postgres. Granted, then you wouldn't get such a nice acronym, but it's a perfectly reasonable technology stack. Oh, and you can throw in the L from LAMP if you want, as well.
When you don't care (Score:2, Informative)
JavaScript in its current form will never have a place larger than simple website scripting in my production environment -- it's unmaintainable in anything beyond small doses and is something we work with because there's literally no other option, not because we want to. TypeScript makes things better, but being better than JavaScript really isn't that tough. It's still not as good as --
Re: (Score:2)
Relations (Score:3, Insightful)
Then you need an account table, a customer table, and a relational table that contains instances of paired keys from each. Learn some elementary set theory for chrissakes! The article is full of other stupidities as bad as this.
I'll bet it does, you nitwit.
Re: (Score:2)
Use the right tool for the job... (Score:3)
And, if either tool works use the one you know best. And, try to write code well, so you don't get stuck when the right decision now becomes the wrong decision later because things change.
From a data store side, there are reasons to use an RDBMS and one or more NoSQL solutions all together. They handle different situations better and if you have any decent level of complexity you find the boxes defined by LAMP or MEAN too confining. I generally stay away from MySQL due to the licensing issues, but MariaDB and Amazon Aurora fit the same space. I used PostgreSQL for one solution. Of course in the AWS case you might forgo MongoDB altogether for Dynamo because why deal with operating Mongo when Amazon will take care of that with Dynamo.
Some of us have to deal with corporate standards and actually neither LAMP or MEAN is actually allowed, which makes this whole thing a pointless flame war.
No joke (Score:2)
If it isn't a joke then what is it? A tragedy?
Re: (Score:2)
To be fair I'm also no fan of what is traditionally considered "LAMP". I personally believe PHP is more dangerous than it needs to be, MySQL is a poor choice relative to alternatives and harbor little regard even for Apache.
MongoDB is built for the cloud
No. Application design limits scalability of non-trivial systems not the data store.
MySQL's structure is confining (and overrated)
The only thing that sucks worse than a good relational schema design is everything else.
Disk space is cheap
JOINS JOINS JOINS... The reason for JOINs is saving disk space... mind blown.
Node.js simplifies the server layer
MEAN makes code isomorphic
General purpose languages are a dead
MongoDB is so 2003. (Score:5, Informative)
Basically MongoDB halved the initial quarter of data storage design and programming. But as the project progressed the time spent screwing with Mongo went up exponentially until the project was shoved out the door and primary feature in version 2 was the complete removal of MongoDB.
I could make a mile long list of places the project stumbled. But a few key ones would be that there are no good data management tools for accessing a MongoDB. The second was that huge schema screwups were way too easy. It was very hard for programmers to get a mile high overview of how data being stored was being structured. That is a data layout was easy but putting the results into your head was really hard.
I am finding other NoSQL approaches are far superior. Things such as use of JSON, memcaches, MariaDB (or the excellent PostgreSQL) working together allows the project to dictate how things function instead of Mongo very quickly shaping the project architecture because of its marked strengths and weaknesses.
Redis is the environment presently being explored for version 4 and so far it is looking very interesting. But I am not joking when I say that at this point I would use access on windows as my backend datastore before I would use MongoDB.
Finish the job... (Score:2)
Why not finish the job, and just move the database to a distributed one that runs in the browsers?
Normalization (Score:4, Insightful)
The fool thinks the only reason for normalization is to save space.
MongoDB? (Score:2)
All I know about it is that it installed with Debian on my laptop. And from time to time, when everything starts to bog down, its MongoDB that is hogging CPU cycles. So I sudo kill `pidof mongodb` and all is well. Nothing stops working or loses functions. So I can't figure out what the fuck MongoDB was doing clogging up my system.
Problems with Node (Score:2)
Re: (Score:2)
Notice how the writer of the article in the last comment says:
"Yeah, I actually have no problem with javascript on the client side. I think its really awesome for a beginner to be able to make static pages interactive relatively easily. However, javascript on the server is a totally different animal."
The solution is obvious, maybe it much more readable and predictable:
Promises, promises, promises
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
Re: (Score:2)
This article is not about nodejs being bad, it is about low experienced programmers doing crappy things with it. It is basically saying: "To architecture good scalable web applications you need to be a smart guy with some experience". Well that is pretty much the same thing for all languages...
The author then goes into a rant that I can only compare to VB6 rants of the old days: It made easier for beginners to get into the bandwagon, so much code written in it sucked, this caused VB6 to have a fame for bein
Why do I get the impression NoSQL guys can't code? (Score:2)
Why do I get the impression that these NoSQL guys know even *less* about proper programming than the PHP crowd?
The problem with NoSQL is, they threw out SQL (well done) but they throw out relations and proper archtecture along with it (WTF?). I'm all for ditching SQL as an apps means to access persistance. It's stupid and wasn't meant for that. Even the SQL DB engineers tell us that. But if you don't understand relations and proper application models, you have no business building webapps or - heavens forbi
I can't believe no one mentioned Meteor (Score:4, Informative)
Meteor ( https://www.meteor.com/ [meteor.com] ) is a javascript framework that runs on top of Nodejs and it is GREAT. It is a full stack solution, it has a view engine (Blaze templating language, based on handlebars), a server (Nodejs) and a database (MongoDB) all bundled up and it just works out of the box, no configuration required. From the meteor website:
"Really, you'd like to use a combination of packages that have been not just tested individually, but tested together, since so much of the complexity in a large software project comes not from its individual pieces but from how they're integrated. Rather than leaving your package system to select the "best" combination of package versions, which could change every day and could be a totally new combination that nobody else has ever tried, you'd like to use a set of packages that has been comprehensively tested by professional release engineers that really know the platform.
That's what the Meteor Distribution provides. Similar to a Redhat or Ubuntu distribution, the Meteor Distribution is a set of package versions that have been tested and recommended for use together."
And that is just one of the great features that Meteor provides. Another great feature of Meteor is that your Javascript code runs both on the server and on the client _at the same time_. Whatever action you make that triggers a state change (change in the database) will run both on the client and on the server, the client has something called MiniMongo that caches the result from the server database and the changes happen without a roundtrip to the server. If the server state is not consistent with the client state Meteor takes care of synchronizing everything. So the application looks like is running locally there is no lag at all.
This drastically reduce the code necessary for example, you don't write form validation code twice, you write it once and show a popup message on the client and throw an exception on the server if something is wrong. Really everything in Meteor works great, there is a really good automatic deploy system (it even deploys to phonegap, also I believe you can deploy your mobile apps to app stores automatically), the API is really small, the meteor packages work great (check out the Velocity testing framework, it is awesome!) and so on
There is one big caveat though, you can't migrate parts of your existing application to Meteor, the only real optional part of Meteor is the View layer, you can discard Blaze and run your own solution. I have had a great time using React with Meteor for example.
Re: (Score:3)
Node.js.
Re: (Score:3)
Are you just looking at things in the office and saying that you love them?