3 ms·

> It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages. Yo

> It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages. You can also do shim servers to translate between protocols - a long time ago, I had to interface with a Rails app (by another team, so I couldn't modify it) with an Emerson (the industrial giant) SOAP API, and what turned out to be effective was a Sinatra shim server that only converted JSON to SOAP. Now I could plug the two together without worry. So - I'm guessing you could have a Java Smooks applet that translates from a JSON API to the EDIFACT protocol, and then you can write your main app in anything you want. PS - Seconding the "don't go microservices", even though I'm advocating for one here - IMO, you only want microservices if they can be fully defined, independent products; a JSON/EDIFACT translation service would probably qualify.

mindcrash 2y ago
I think in this case a well defined modular monolith would be a excellent starting point, especially if you need to (1) build from zero and (2) hit the ground running with a small team (without all the extra things you need to pay attention to and create solutions for when going the microservices route). The great thing about the modular monolith is that it gives you a fantastic foundation to grow: You can still invest in multiple teams each handling a certain part of your problem domain (due to the modularity); and because it is modular you could easily break it apart, and evolve it, into a microservices architecture if and when there comes a time you need to do so (due to extensive problems getting code shipped, or difficulties concerning NFRs defined for the architecture, for example scaling issues in production).
- RangerScience 2y ago
  IDK. I don't have much experience with modular monoliths. What experience I do have says they'll just become regular old monoliths... ...unless you still do the same thing I'm advocating for when considering microservices: defining, and treating, each chunk as a discrete product. If you can do that, great! MM or MS will both work, and you can probably decide between them based on the other factors you're dealing with. If you can't, I would expect you to end up with a regular old monolith, so you might as well lean into it.

mindcrash 2y ago

I think in this case a well defined modular monolith would be a excellent starting point, especially if you need to (1) build from zero and (2) hit the ground running with a small team (without all the extra things you need to pay attention to and create solutions for when going the microservices route). The great thing about the modular monolith is that it gives you a fantastic foundation to grow: You can still invest in multiple teams each handling a certain part of your problem domain (due to the modularity); and because it is modular you could easily break it apart, and evolve it, into a microservices architecture if and when there comes a time you need to do so (due to extensive problems getting code shipped, or difficulties concerning NFRs defined for the architecture, for example scaling issues in production).

RangerScience 2y ago
IDK. I don't have much experience with modular monoliths. What experience I do have says they'll just become regular old monoliths... ...unless you still do the same thing I'm advocating for when considering microservices: defining, and treating, each chunk as a discrete product. If you can do that, great! MM or MS will both work, and you can probably decide between them based on the other factors you're dealing with. If you can't, I would expect you to end up with a regular old monolith, so you might as well lean into it.