0

My project comprises of serveral bounded context which communicate with each other with RabbitMQ

The front end of the project is written in C# and the backend is in Java.

The RabbitMQ communication happens with JSON payload. The backend of the application defines these payloads as JSON-schema files that are used to autogenerate java classes using jsonschema2pojo. The same JSON-schema files are used for autogenerating CSharp files for the front end. RabbitMQ handlers are written on both sides(frontend and backend) to handle/reponse to payload queries.

The communication between frontend and backend needs to happen over RabbitMQ as both the applications run on different language platform.

Now, the bounded contexts defined in the backend also uses RabbitMQ to communicate with each other. This causes 3 problems

  1. The intercommunication between the bounded context may fail(eg. producing side using a different routing key than consuming side) even having completely tested(integration tests), as the bounded context are tested independently of each other.
  2. If there is a change in Json-Schema, both the side, producing side and consuming side needs to be changed, as they depend on the autogenerated Java classes created from these Json-schema files.
  3. If I want to change from RabbitMQ to any other message broker(for example Kafka), this will require a massive change to all the backend adapters(producers and consumers) and test cases(Those 100's of test cases! Ohh no!)

I want to develop a library which will bypass communication with RabbitMQ(or any other message-broker) wherever possible and make a Java direct call between publisher and consumer just like any other library. The RabbitMQ call shall only be used in case direct call is not possible(for example communicating with frontend).

This library shall give me 3 advantages

  1. It shall act as a proxy between bounded contexts, test cases and front end.
  2. It shall allowme to write test cases for my bounded contexts in a black box manner leaving the implementation details on the library itself.
  3. Even if there is a change from RabbitMQ to any other message broker, it shall only be limited to this library.

I plan to generate rabbit handlers for Json-schema files. This shall prevent me from manually writing them and I could also use the Json-scema files to generate similar handlers for C#.

I request some suggestions with how to move ahead with this problem.

1

First you don't need to write such library because most probably it already exists. What you need is some embeded RabitMQ implementation so that you can potentialy perform a more (integrated) end to end type of test. Just googling I found one such https://github.com/AlejandroRivera/embedded-rabbitmq

With regards of point number 2 this is entirly separate question that is not valid only in the context of MQ but in the context of any json based API.

There are enough resources online describing how to design a json schema in such way that it is future proof.

You can google a term named "Schema evolution" it is supported out of the box for Avro. A lot of it can be achieved with json, though not everything.

Here is a very good article about API evolution https://apisyouwonthate.com/blog/api-evolution-for-rest-http-apis

showing how to design your API in such way that you don't need to release new versions for each change.

1
  • I have updated my post
    – Nishant123
    Mar 2 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.