1. Hi there, I was following your tutorial, but Im stuck, I have everything like your repo in github, but I get this notification:
    The import org.springframework.data.mongodb.repository.Query cannot be resolved

    So im not able to import @Query annotation.

    Please could you tellme if this error is caused by the version of spring boot Im using the 2.0.2 release

    1. Author

      Did you change only the dependency or something else? Please post your question on GitHub as an issue in the repository, I’ll tag it as a question.

  2. Exactly Moisés, that’s the point that I missed.

    I’ve applied reactive in a stream solution and it’s work very well.

    You’ve confirmed my opinion about reactive, you cannot applied it as solution for every problem, but it depends a lot on your use case and how you’re going to access the data and not only the data stored into the database.

    I think it’s not so clear this concept of this topic, specially in the practical examples the I found out over the net.

    Thanks again for your time and your suggestions.

    1. Author

      you cannot applied it as solution for every problem, but it depends a lot on your use case and how you’re going to access the data and not only the data stored into the database

      Indeed, that’s the key. I tried to reflect on that in the conclusions of this guide and a bit during the introduction, but maybe not deep enough. I’m working now on the book and there I’ll try to give a bit more of practical comparison and insights.

  3. Hi Moisés,
    Sorry, it’s my fault, I hadn’t seen your test before writing my comment.

    I tested only the repository driver with a big number of users and req/sec and I found out big difference between reactive and no-reactive solution.

    Applying your test I get your expected result, reactive faster than no-reactive but I tried to make a test editing your method:

    excluding pagination and delay in order to compare it with no-reactive one:


    With a load of 10,000 entries I got the last solution better performant than reactive repository; I’d like to know your opinion about that conclusion.

    Thanks again for your time

    1. Author

      I guess you’re measuring the performance of the overall process of retrieving all the 10k entries. If you do that, I think it’s normal that you find the reactive solution slower since there is an overload in the implementation in order to make the whole process reactive. I’ve tried to find the paragraph explaining this same thing in the Project Reactor docs and Spring WebFlux (since I remember having seen it) but couldn’t find it this time.

      Take into account that if you ask Mongo for 10k entries in a reactive way but you block your process waiting for them to measure the amount of time to get the whole set, and you do the same in a non-reactive way, the latter might perform better since Mongo knows in advance that you can wait for the complete 10k entries, thus avoiding any kind of implementation overload. I don’t know how the mongo reactive driver works, but it surely requires some extra plumbing to make it reactive.

      The advantages of retrieving data in a reactive manner are different. Think of this: when you ask for those 10k entries, how long does it take to get the first 10 so you can send them to your client? Much less than using the blocking style.

  4. Hi Moisés.
    Thank you for sharing this article, I really enjoyed reading it.

    Just a question: have you ever tried to compare Reactive repository with a classical repository in order to understand the scalability of the last?
    I avoided using the stream of the output to keep the solutions comparable.
    Well, I’m struggling to make solution based on reactive Mongo repository performant as non-reactive solution but I keep on seeing better result with non-blocking.

    I published my result on github https://github.com/MarcoGhise/ReactiveMongoPerformance and I’d really appreciate to know what you think about this issue.

    1. Author

      Hi Marco,
      Given that I provide performance tests too, just give it a try and extend it / modify it to include Gatling tests if you wish. As you’ll see, I got different conclusions but scenarios might differ.
      Let me know if you find something I missed.

  5. Hi Moisés. I follow this tutorial step by step. I boot the server and everything seems fine. But when I try to access http: // localhost: 8080 / quote-reactive-paged or another path, I get error 404. Any idea about what may be failing? Thanks!

    1. Author

      It could be due to few different reasons, e.g. the request mapping annotations are not properly configured.
      You can try comparing with the code in the GitHub repository, or if you want to further investigate please post your question with more details on GitHub (as an issue).

  6. thk for great post, i have two question that hope u make me clear,
    1/ why don’t u use @autowire anonation for our repository instance
    2/ i’ve not understanded about this snippet more

    QuijoteDataLoader(final QuoteMongoReactiveRepository quoteMongoReactiveRepository) {
    this.quoteMongoReactiveRepository = quoteMongoReactiveRepository;

    whether it’s a contrustor of this class or its have another special

    thank for help

  7. Hi and big thanks for this great post.
    I have one question : where is the mongo url in application.properties. ( who the backend can see the database in a container).
    thank you again for sharing your knowledge

    1. Author

      Hi Amin,

      Thanks for your feedback! I’m using Spring Boot’s Externalized Configuration to pass that property (which would correspond to spring.data.mongodb.host) via an Environment Variable that you can find in the docker-compose.yml file. To be precise, here it is: https://github.com/mechero/full-reactive-stack/blob/master/docker/docker-compose.yml#L20

      In this case, I’m passing only the host since the port is the default one but, if you need extra configuration, it works in a similar way.

  8. Thanks for these tutorials. Is there any particular reason why you are implementing your own CORS filter instead of configuring CORS through @CrossOrigin annotation?

    1. Author

      Good one. That’s also possible, but take into account that the @CrossOrigin annotation works only at method or class level for a controller. That means you need to put that annotation in all your controllers to make it work. I’d rather use that approach when a fine-grain configuration is needed, while the CORS filter configuration applies overall to the entire application.


This site uses Akismet to reduce spam. Learn how your comment data is processed.