As a web developer, choosing the right stack for your project can be a critical decision. With the rising popularity of React, many developers have...
For further actions, you may consider blocking this person and/or reporting abuse
That's so difficult to decide, it depends a lot on the project and deployment method, my here are my favs in order of preference.
UI
Databases
Frameworks
Thanks for your comment.. Yes, you're absolutely right that the choice of a React stack ultimately depends on the specific needs of the project and the deployment method. Material-UI & ChakraUI are both fantastic choices for UI frameworks.. I appreciate you taking the time to share your experience...
Is this post from 2009? Since then...
If you just started programming with Khan Academy you might still learn MERN...
Ant Design lib is also a masterpiece that no one ever mentions.
Let's stop pushing MongoDB everywhere, it's harmful.
In which way is MongoDB harmful? Are there security issues we should know?
Also - express is still a pretty solid choice for simple projects.
Besides that I fully agree with replacing redux with contexts, that simplified things a lot!
MongoDB is harmful because 99% of developers use it as a general DB, without paying attention to the fact that they will loose ACID transactions, have to denormalize their schemas in order to compensate the lack of SQL JOINs, and deport the complexity in their own code instead of relying on powerful SQL transactions.
All of this for what? JSON. But nowadays you have JSON in MySQL and PostgreSQL which are much more advanced and faster databases than MongoDB.
Also you can't do big data with MongoDB, as soon as you activate sharding you loose half of the aggregate operators and query computing is not parallelized so if your dataset is above 5GB you will end up with a 30secs timeout.
I've done that mistake for many years, and going back to the SQL world saved me.
I'm not saying pick MongoDB, use the CORRECT databse for the work.
But, almost every NoSQL supports ACID transactions.
mongodb.com/basics/acid-transactions
And the correct database for 99% of the work is not MongoDB.
ACID has multiple degrees of consistency... serializable transactions, MVCC etc... it's easy to throw "ACID" on marketing pages, the devil is in the details.
So many use cases don't need insane level of consistency.
The internet on a whole is basically "eventually consistent" and that becomes more apparent the larger the scale and reach of your platform.
It is probably better to architect for eventual consistency everywhere over pinning hopes on a database to save you. Of course, at a smaller scale or if everything is in one data center, sure. I guess. At small scale Mongo will be consistent just fine.
I get there is a lot of bad feelings with MongoDB. It had a rough start. It isn't my go-to database myself. Personally, I use DynamoDB (or DocumentDB) on AWS, Firestore on GCP or CosmosDB on Azure. If I need relational data, I first look at a graph database like ArangoDB. If I need analytical data, I look at something like GCP Big Query. Complex searching? ElasticSearch or TypeSense.
My "source of truth" databases are almost always a super fast and super scalable NoSQL. Most data is just a bunch of documents anyway and 99% of the time I am accessing them by ID. I also follow domain driven design, so by core business domains access their data through APIs. So a shopping cart service would get inventory from the inventory API and the pricing from the pricing API and never through a JOIN in a single database.
Obviously, there are cons to a distributed data model. Not as much these days. The tooling has come a LONG way. Storage is cheap, having a data stream from the transactional DB into an analytical DB is easy enough. Or if I want a powerful product search engine, then that might have a "dirty" copy of product, price and inventory where the actual product landing page gets the data directly from the APIs for more "up to date" information.
Would I be fine using Mongo as my pricing DB. For sure. The advantage of this pattern is that you really can pick a DB optimized for the data. MonoDB might not be the best for pricing data. I'm looking up price by a productID and maybe some other filters/projections. AWS DynamoDB would be super fast. GCP Firestore as well, plus it has a bit more query tools. Really, a super fast columnar DB is pretty ideal in this case. An RDMS is just going to be overkill.
To take advantage of the platform as a service model we live in, I think it requires a shift in thinking on how we build large enterprise platforms. And if you are building small - well, the DB choice doesn't really matter all that much other than the cost to run it.
by reading the other comments I just noticed that this post attracted frontend / fullstack devs, who mainly write JS / PHP...
makes sense no one understands the importance of JOINs and SQL transactions here... good luck with MongoDB
Again, transactions are a part of just about all databases these days.
As for JOINs. that is a use case. It would be important if you are doing analytics for sure! If you are joining data cross-domain in a large enterprise platform - well, that is just going to cause huge issues down the road for scalability and waterfall release schedules.
RDMS is not a bad choice. It isn't the ONLY choice anymore though.
Again, from my example - you can shove everything in an online commerce app into one RDMS and join your price, inventory, user data, coupon data, etc... all in one huge SQL query.
Now, changing the schema for inventory means multiple code areas could break. It is way harder to maintain a V1 Db schema alongside a V2 Db schema than following an API-first design for that same data.
But, maybe you won't scale huge. Most people don't. And again, I am NOT a person who goes for MongoDB as my primary DB. It is pretty foolish to discount it as an enterprise grade / production ready solution. I would suggest to anyone, if starting a project, consider both popular and up-and-coming DB as solutions and don't be afraid to use more than one. That's the nice thing about microservices and domain driven design - use the right tool for the job.
I forgive you.
Next Js for sure.
In most projects it just doesn't make sense to have a non-relational database, so MERN rejected to what matters for answering the question of the post.
You can use Mongo along Next if you need so btw, just add mongoose and you're good to go.
I usually use Next Js with Sequelize (PostgreS, MariaDB...) because you have a monolithic App that works API-first so you can scale it whenever you want.
To be honest, Vercel people did, and are doing a great job in "standardizing" the development process around React while providing great features out of the box that most projects need sooner or later, plus the SSR thingy is king when dealing with public websites or web Apps both bor UX and SEO.
Aside from that, you can sure use Gatsby or any other headless CMS along with Next JS (idk why you set Gatsby as its own "stack" 😅). The same can be said of having Next JS to work with Redux or MobX, though most projects don't really need neither one or the other.
Why? In most projects I see people using CRUD methods to access documents. I think I can count on my fingers the amount of times someone actually needed "relational" data.
It is super easy to JOIN that user data with the inventory and pricing to fill out the shopping cart. I do get that. There are so many times that I want to break those separation of concerns and just read the data directly.
The reality though, if I actually keep my business functions in a domain design and access domain data through APIs, events or some other clearly abstracted (loosely coupled) pattern, then I now can scale faster and develop faster with larger teams.
So yeah, now the cart service has to call the pricing, inventory and user services to gather up all that data. I pay for this in some additional milliseconds. But now if inventory needs to change into a different DB for performance or if the users domain needs to change their DB schema - they won't break my code. Well, as long as their honor their API contract (or other public interface).
ORMs are cool. They make things a bit easier, for sure. That's the reason front end full stack devs keep picking it up. A tool like Prisma is popular and easy to start up with. The "better" choice would be to pick a database that handles the data in the best way possible. User data, for example, is often very document in nature and has such a high read count, I almost always put it in a fully managed NoSQL that can scale horizontally really well.
Thanks for your detailed comment.. Yes, I agree with you that the Vercel team has done an excellent job in standardizing the development process around React and providing many useful features out of the box..
I appreciate your point about the possibility of using Mongo along with Next.js by adding Mongoose..
For Gatsby, I mentioned it as its own "stack" because it is a popular framework in its own right and while it shares some similarities with Next.js, there are some key differences that make them distinct. But as you mentioned, it is entirely possible to use Gatsby along with Next.js, depending on the needs of your project..
I also appreciate you taking the time to share your experiences and insights into the Next.js stack..
Thank you again..
"In most projects it just doesn't make sense to have a non-relational database" -> there are tons of cases where this statement is wrong. Like for any case where you don't often combine data from different objects.
I’m old-school, and so while I appreciate Node/Express, I feel like I don’t have all the tooling I like from developing in PHP using Laravel. It’s super easy to make very expressive models that emit themselves as JSON responses for APIs, with React or Angular in the frontend. There are things I like about Angular, and things I like about React. I use React in my day job so I’m leaning that way currently, but I really liked Angular’s dependency injection for services, and RXJS’ observables. We use Redux during the day, but I’m playing around with just using React’s Context API, and it really simplifies thing when you only have one or two states to maintain.
Agree. I love the tooling and DX when using Laravel. For frontend, my choice is React, never tried Angular.
I am a solid Next.js enthusiast.
That's great to hear that..
i learnt a lot of new information about React, thanks!
I'm so glad to hear that you found it helpful. Thank you for reading it..
React - Meteor - MongoDB
T3 Stack
Thank you for this reference. I will try it out..
Nextjs with useReducer implemented Redux.
Yes. A great choice..
Nextjs anytime.
Indeed..
Honestly I can't choose between Next.js and MERN stack. Nice post though!
You can choose MN 😂😂
Next brings Express React and Node on its own, you just add Mongo (or any other DB) on the stack and you're good to go 😁
true :)
Thank you for your comment. Both Next.js and the MERN stack are fantastic tools for building web apps and it can be challenging to choose between them. It really comes down to your project's specific needs and requirements..
PERN - React, Node.js and PostgreSQL. The easiest way to get started with it and have everything taken care of for you is by using Wasp
Interesting. Thank you for sharing
next js is my favorite.
Mine too..