I'd recommend GraphCMS! Full disclosure, I work for the company. The single biggest reason to choose GraphCMS is because we support read and WRITE with GraphQL - the next generation of web APIs. GraphQL write makes importing of data really easy and working with GraphQL as a read layer is just so much nicer than rest for the vast majority of projects. You don't have to spend time managing multiple network calls, you can just describe all the data you want and get it in one go! Plus, it's a next-gen technology to add to your developer tool belt that's being adopted by major players like Facebook (who wrote the spec), Github (so, Microsoft!) as well as Shopify and many more. Check out some of our examples repos to get started fast. Examples: https://github.com/GraphCMS/graphcms-examples Our Website: https://graphcms.com/
I've used https://graphcms.com/ to achieve a similar goal. It has a free tier, and has a web editor, you need to get familiar with GraphQL, but it's not too hard. The static frontend (that you can host on netlify or whereever) makes requests to graphcms to retrieve the content. Then the client will log in to graphcms and upload the content there. A bit finicky, but worked for my use case without anyone spending any extra.
100k users will take some time but this is still a trivial amount of data for most databases. It's not until you get to millions of records that performance gets more interesting. Along the way, you can also perform backups and upgrade your db instances for better performance and tuning.
Depending on how your app is written I might start smaller and work up in pricing. If you can easily upgrade from 10 to 25 dollar plans in any service provider don't overthink it. Heroku is probably a lot more feasible than some other apps. If you don't need SEO you can do a create react app and deploy it as a static site and pay close to nothing other than any api costs.
Cypress is pretty easy to pick up, you also have selenium and other services as well. These can easily simulate a user experience and verify if problems exist.
Additional food for thought. Have you thought about using something like a headless cms? An example is graphcms. You pretty much get a free graphql api and can defer database life and scaling till later. And strictly speaking, I wouldn't be surprised if you're in the free tiers until you scale up. You can migrate the data since it's an API into a database later after you have captured market fit.
Dessert for thought. While the idea of gaining massive amounts of users overnight is pretty tempting, if you can't monetize the application then you will be left with a nice bill. In some cases, you might easily want your app to fail and not scale if you don't want your bank account to get hit with a money truck not carrying any money.
Unless you want them editing the source code, you will need some sort of headless content management system. Here are a few I'm familiar with:
If you're writing a decoupled front end with React/Next/Gatsby, then, without knowing your content design requirements -I'd say for 90% of content driven sites - you can use:
https://www.contentful.com/ https://prismic.io/ https://graphcms.com/
Don't worry about dashboards, authentication, uptime, database management or migrations - just grab the content from the API, and render however you wish.
you dont really need to pay for a CMS per se - wordpress, drupal, october, grav, etc - the free/open source options are endless.
however if you take a 'raw' bunch of FOSS code and build off it, you will generally need to pay for hosting somewhere; the other alternative is 'software as a service' where you either pay for a managed version of one of the above products (e.g. wordpress) or a dedicated entrant to that space like graphcms
as for when the free tier of a SaaS becomes insufficient, that really depends on the SaaS, and your needs, there is no general answer. you should be able to figure out from https://graphcms.com/pricing/ no?
anyway the packages are all per project per month so unless each of said family members are up for covering $50/mo hosting costs (which is frankly enormous) that looks like a money-loser for you
Several people have already answered this. But yes, it's completely doable. Essentially you have a proxy layer that will handle the syncing of your headless CMS and the MongoDB database. Then your MongoDB database will update your website via the websocket/real-time connection. I work for a company called GraphCMS (https://graphcms.com) which is another flavour of headless CMS. We've seen companies sync content from a headless to many different kinds of additional data stores. Does your app need to support some kind of real-time requirement? If not, you could also consider implementing something with webhooks to invalidate the cache on your node server.
Btw, if you're interested in using GraphQL and want to build it as an open source project, I have need for this (I'm an IT Director of an international NGO) and would love to help you build it. Check out https://graph.cool and https://graphcms.com, and look me up on https://github.com/DanielBodnar
For the beginning you could also choose a free tier from a cloud provider (AWS) or use headless CMS like Squidex (https://squidex.io), Graph CMS (https://graphcms.com). When your project becomes bigger you will very likely change everything several times ;)
This is by far the biggest problem with Firebase. It stems from the fact that Firebase lacks any way of declaring relationships in your data, or doing complex queries.
You either complicate your reading code by doing these kind of acrobatics, or you duplicate your data.
The problem with duplicating data is that:
1) When (not if) you need to edit that data, you will need to do it all over your database.
2) Your writing/editing code will become a mess
For a simple use like yours this seems trivial, but once your structure grows you will end up in deep shit. You have 2 collections here, but what if you have 50 collections with complex relationships?
You can decide instead to do looping acrobatics while reading but what if you want to have multiple levels of relationships? Again, with your current use case this might not seem important, but you will end up in deep shit when your project grows.
And if you do end up in deep shit while your project is in production you will hate Firebase because your code will be tightly coupled with their SDK.
A better choice would be to find some GraphQL solution. This way your data source is not tightly coupled with your front end and you can replace it anytime. There are many solutions like Graphcool or GraphCMS that allow you to spin up a backend in no time, without introducing all the problems with Firebase.
Curious if you ever found anything? I'm using Directus but every time I start a new project I have a google to see if anything new is out there. Something node-based that I could just spin up in pm2 would be incredible.
GraphCMS is the latest cool looking one, but can't be self-hosted as far as I can see. https://graphcms.com/