I've been reading articles about node.js tips, tricks and best practices in general. I found one that mentioned that it is convenient to really think and approach apps in terms of microservices. I've toyed around with that before, but I'm still not quite clear when is best or what criteria to use.
For example, now I'm working on an app (not for work, but a hobby of mine) to record quotes from books I read. So, I've written node.js API with two routes: A POST route to recording the quote on a MongoDB instance running on a cloud, and a GET route to read quotes.
This is all one single app. Does "thinking", in terms of microservices, mean that I should write two different apps, one for posting, one for getting, each running on its own container?
I'm familiar with Kubernetes, and Openshift so the tech details are not much of a problem. My concern is in regards to how to make a decision in regards to splitting the apps, the separation of concerns bit of the architectural design, so to speak.
Thanks in advance.
Typically, microservices are broken around logically distinct pieces of data and operations. Since both the POST and the GET in your example deal with the same data, and complement each other's operations, breaking the GET and POST operations apart as separate microservices makes little sense to me.
As described, your application is small enough that there's no obvious boundary between components that could be further isolated for better flexibility.
Or put another way, this service already fits most definitions of a microservice, and doesn't lend itself to further decomposition.