Comment by mindcrash | Hacker News Reader

Comment by mindcrash | Hacker News Reader

> "This feels like a quagmire in which development can quickly stall."

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.

If you do not want to do the heavy lifting yourself, both AWS and Azure provide SaaS services to do the heavy lifting for you (AWS: B2B Data Interchange, Azure: Azure Logic Apps)

> Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

If you can provide a good salary and conditions: absolutely. And I should know, because my previous stint WAS in logistics :)

> Strategies for attracting and retaining tech talent in a non-tech industry

Provide a great work environment, good salary and conditions

> Experiences transitioning from third-party to in-house software (success stories and cautionary tales)

Start as easy as possible and don't hire anyone who wants to build a microservices based platform from scratch w/ almost zero domain knowledge at your org. Because that road will lead to nowhere. (Ask my previous colleagues who decided "we" should. I was against. They are still working on it, 3 yrs later, and nothing has been deployed yet because it still does not work properly.)

> Potential pitfalls we might not be considering.

Do not go the microservices road unless you really, really, really have to (and with good arguments!)

Need any more tips? Happy to help.

> 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.

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).

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.

I'm not familiar with EDIFACT, but just from the context I'd assume that

a) there is something on the other end that expects the data to be exactly in a specific format, which may not be documented correctly or in a language your devs can read,

b) the consequences of not getting it 100% right are expensive,

c) there are a lot of these "somethings", each potentially requiring their own format/special quirks for which the provider may have already built workarounds.

Is that the case? If so, trying to build anything yourself will be a nightmare, and my first approach would be to find something that handles this part and beat my data into it, even if it means using some fully-featured software package just for this feature.

EDIFACT is designed to fix _exactly_ this. It does not only specify the _what_ but also the _how_

Wikipedia provides a pretty good explanation: https://en.wikipedia.org/wiki/EDIFACT

The beauty of EDIFACT by the way, is that with enough time and effort it can get parsed and validated using any text processing tool at your disposal because everything is _rigorously_ specified by the UN.

For example I once had to do it with a set of specs, standard Linux text processing tools and a sprinkle of shell scripting for a school assignment.

I would have assumed that it's meant to fix it, but I wouldn't expect it to actually have fixed it.

Has it? If so, that's a pretty remarkable feat, and I'd love to be wrong about this one. And are the open source libraries good enough at it?

Reply on news.ycombinator.com