typically you build apps as single 'monolithic' apps where all your code is in one place.
or
You split your code by criteria... say 'function'. So maybe seperating UI (front-end) from server/API (backend).
Reason is if you wanted to change part of your app its easier if there are clear boundaries between each part rather than mangled solo entities as with monolithic.
Microservices is an extreme version or seperation of concerns/function whereby you create 'black boxes' that handle one thing (auth, orders, stats, images) - each of those 'services' provides a mechanism for intra-communication... typically via an API (REST). sounds great in theory and makes large apps easier to distribute across tech stacks, geo and developer teams without worrying about other services... but... ensuring all services are secure, share information, self heal (recreate themselves when crashes occur), auto find each other across the interweb (discover) etc etc is a massive P.I.T.A.
Search 'Netflix microservices' on YouTube... reality is never as nice and clean as theory.
Also Orielly and other have books on M.S...
I would say build the monolith first (or simply seperate client from server/API), then split if need... rinse and repeat. Its gonna be real hard going if you're building a multi tenant app for most things and trying to start with M.S
When you need to scale... iterate. if M.S makes sense, split out a function and carry on.
Also check out Docker... sorta encourages M.S approach. Quickly create/destroy and deploy new 'service containers' etc...
Github has some examples too
https://github.com/cer/microservices-examples etc etc
Good luck