Nothing here yet.
Nothing here yet.
No blogs yet.
Both @fibric and @sandeep have explained it much better than I could, but one thing worth pointing out, is that this statement isn't correct in the first place > "requests having some sort of blocking task like DB access or some sort of File System access that needs a separate thread from node's single thread of execution." These operations don't really "go to a thread" that waits for them. From the libuv docs ( http://docs.libuv.org/en/v1.x/design.html ): The event loop follows the rather usual single threaded asynchronous I/O approach: all (network) I/O is performed on non-blocking sockets which are polled using the best mechanism available on the given platform All I/O is handled through signal handling mechanics that don't require an active thread. If you read that doc, you'll see some temporary blocking is involved for signal handling, meaning blocking happens for only a small fraction of the complete wait time[*]. So yes, libuv (and by consequence node.js) is as non-blocking as it gets. [*] at the File System level, this depends heavily on the platform and the Filesystem in use, but libuv will ALWAYS try to use the best mechanism possible.
I really like this answer. I would add the following bit of info: NoSQL databases exploded in popularity at a time where most projects were already using some serious object oriented abstractions of top of their relational database systems and - most importantly I suspect - were building their queries in code and not SQL. The expressiveness of SQL becomes a non issue at that point, and it all comes down to how well and how fast you can do the things you need to do to the data, and this will depend on your data, the specific operations you want to do on it and the strengths of your data store.
Jan, i see where you'r coming from now. No option is without pitfalls of course. My perspective on the PaaS was focused on flexibility and architecting a solution that would be flexible down the road. For example, writing for heroku forces you to write a "service" and migrating away from that is fairly accessible.
Jan, I don't disagree, but I don't see it a big issue. Like with the data size, using a PaaS defers some problems to a later date, buying time to worry about building the actual platform and not its infrastructure.
Your question is a little hard to answer because it leaves so much to the imagination, so allow me to state it as I understand it: "I'm starting a new project with lots of growth potential. I don't know exactly what we'r building yet so I need to make flexible choices. What do you recommend?" This is an extremely common problem. The simple answer is "It depends on what you'r building", but thats often an unknown until after you get started. This makes it really important to ask the question you'r asking, but the actual answer is surprisingly simple. Chose what you know. Any tech stack you know today will have support for the tools you need for growth, when the time comes. PHP scales, Ruby scales, Python scales, .NET scales. Its not about the stack you chose, its knowing how to architect for the scale you need . Really big platforms run on multiple data stores, multiple stacks, multiple services and multiple projects. But you'r not writing a Big platform. And you don't have Big Data ™ yet. You have an idea, and you need to get it running. You need speed of development and nothing else. The only thing that gives you that is what you are already comfortable in. Someone wrote a really smart thing about how to write apps that have the flexibility you'r looking for : http://12factor.net . Open that link, bookmark it, then come back. That link is awesome but here are a couple of off the cuff pointers, to get you off the ground: Consider using a PaaS from the beginning. This forces you into some good architecture patterns from the start. STAY AWAY FROM WRITING TO DISK. Writing to disk ties your app to the local system's filesystem. You want to be able to run many instances of your app behind a load balancer. keep sessions in a service (memcached, redis, even you'r database is a better choice than direct to disk) keep any artefacts (like uploaded files) in a service (NFS, FTP, ceph, S3, anything that is not direct to disk) Use a CRUD framework. Ideally one that makes it easy to model your data and start playing with it very quickly. ( Django (python) , Ruby on Rails (ruby), Laravel (php), .NET MVC (.net) Play Framework (java), Nodal (javascript), Meteor (javascript) ). The database you chose doesn't matter, until it starts to become a problem. This will never happen before you have actual users generating actual traffic and ... hopefully, actual revenue. Its not essential, but keep an eye out for ease of building a REST api. Your framework of choice should have your back on this too. (Django Rest Framework is a pretty good example). All the frameworks listed will help you in some way or another. You will need this when you realise your stakeholders want a mobile app. Get acquainted with offline processing solutions. You will need this sooner that you expect, and not due to scale, but due to sanity. This forces you to think about what tasks need to be done outside of the user's flow ( Celery, RabbitMQ, NSQ, Redis, even Gearman is better than nothing ). Your framework might have some abstraction for this. Find it. Use it. At some point, you should start thinking about your workers as services ;) AVOID BUILDING NATIVE APPS ENTIRELY IF YOU CAN. Cross platform solutions are a real thing. Unless you'r building a game, and even then there's Unity. (Unity, phonegap, cordova, Xamarin, electron, node-webkit) You may be thinking "Thats not exactly sticking to what I know, you just gave me a laundry list of stuff to go learn!" . You'r right. I did. Thats because you'll need to learn each of these to grow your platform, no matter what language / stack you are coming from. Knowing these classes of tools, even just how they work and the problems they solve, is what will get you through all the stages of growth of your company. I sincerely hope that is helpful, and I hope you have a great time with your new startup :) Best of Luck! PS: I chose to ignore your point about costs, because nobody can have any type of idea what those will be until you yourself know more about what you'r building and storing. Its a non issue until you can actually articulate the use case to yourself, and at that point you'll know how to do the math yourself.