I have a 5$ droplet. This droplet is for development purposes. I want to create a graphql api with node.js on my mongodb database to be used in my mobile app. i am expecting around 200,000 users of this app
Questions: Considering scaling, ease development, continous integration among others :
Should i use one docker container for both the nodejs and mongodb or should i use seperate containers?
Should i use two droplets each for the nodejs and mongodb stored in their own docker container?
Should i even use docker?
In summary i just need advice on how to structure this project
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $200 of credit to try our products over 60 days!
If you have an expectation of 200k users going in, I’d recommend separating NodeJS and MongoDB from the start – that way you’re not having to do it later on.
As for using containers – it really depends on preference. I honestly prefer bare metal (in the case of dedicated servers) or staying at the hypervisor level (in the case of a VPS). Some projects do benefit from containers – it more so depends on your development cycle and how you prefer to manage it.
If you develop with Docker locally, it’s a natural progression to use it in production. If you develop without it locally, you may find that initially, it’s a bit more complex than it would be if you were to not use them.
In terms of overall setup, it’d really depend on what the application is doing as to what the best route would be. Speaking from experience with MySQL/MariaDB/Percona, two servers generally won’t handle 200k users unless they aren’t doing much of anything and only a handful are active at any given time, thus you need to work on a plan that allows you to scale efficiently, but quickly, as the need arises – and then scale back when demand drops (if preferred).
My first response would be, that’s never going to work. Unless you’re hosting static files and no database queries, a $5 server is not going to handle 200k users.
Let’s talk about requests, since that’s a number used for dimensioning a server. If your app only downloads data 1 time every day, then 200k users would result in 200k requests. If there’s a login and users can browse several views, then it would probably be closer to 5-20 requests, meaning 1-4 million requests per day.
If every request is a static file - meaning there’s no user-login or anything user-specific, then it’s fairly easy to have Nginx serve that data extremely fast on limited resources.
But I’m guessing there’s logins, dynamic pages (what a typical web-app is now), then you would probably want to split the database from the rest.
So in turn having 2 servers/droplets to begin with. Server1 with Nginx proxying dynamic content to Node. Server2 running MongoDB. It would be very easy to scale either server (it would take less than a minutes downtime).
And in the future you could create load balancers as replacement for both servers and have several web servers and database servers instead of just a single one of each. But nevertheless, I don’t see how either Node nor MongoDB would be able to handle that load even on separate $5 servers. Expect to use more money on each server and if you don’t fine-tune the servers (tweak the configurations) expect to use even more money.
I’m not a big fan of Docker - I prefer to keep it as clean as possible, because you’re already in one container (the virtual server sitting on top of the physical hardware). And Docker also adds the extra overhead. But if you’re already used to Docker, then I would recommend that you continue to use it.