"most of us are just writing our programs in microservice way". Be careful with this statement, because what "microservice way" is is definitely not a single way and I would say that many times it is done wrong. The reason for this is that many developers create microservices based on entities: User, Blog, Comment, Category, Payment, etc. This sort of design creates a web of relationships where all services have dependencies on all other services and the requirements of creating queries with joins on data from multiple services appear.
So, I would say, the first thing you should do is: accept that your service boundaries are likely to be wrong. A service should be able to perform its business goals without requiring data from other services. I have a strong feeling that this is your situation. This means that you should be able to do a query in a single service and return a list of result ids. Then use this ids to query one other or multiple service to create the full information that needs to be returned to the user (for example, the user name, the user reputation and the text of the blog post will likely live in 3 different services).
Now, if you are 100% sure that your service boundaries are correct and you still find a situations where you need to do queries across multiple services, you have a couple of options:
- Create a search engine: This could be firing several searches in parallel to multiple services and combining the results, or doing a search in one service and then call other services to filter out the results from the previous one.
- Use a Search service: this service aggregates data from multiple services and indexes it in a way that allows efficient searches. This is useful if you want to do complex queries like full text search on all blogs and comments, searches based on multiple categories or tags, users, etc. These services normally sort the results based on % of match. If the searches are complex, it's best to use a third party service and not try to build your own.
Regarding your last question "Or should I accept the inefficiency if I go on the microservice path?" I would say that a properly designed microservices application shouldn't be more inefficient than a monolith, considering "efficiency" not only the speed of a single query, but a property of the whole application (performance, stability, mantainability, etc). If your microservice design is not better than your monolith design, definitely go for the monolith.