search

devonfw / devon4j

devonfw Java stack - create enterprise-grade business apps in Java safe and fast
Apache License 2.0
83 stars 87 forks source link

Improve "type of services" documentation #341

Closed hohwille closed 3 years ago

hohwille commented 3 years ago

Aint this kind of obsolete? https://github.com/devonfw/devon4j/blob/90660aaa32ca7f4a81d160346703a49b3ae0f06d/documentation/guide-service-layer.asciidoc#types-of-services

We should not propagate SOAP anymore that is a dying technology. Nowadays REST is state of the art and it is recommended as "external services" as well. If we want to say something about this topic at all we should consider "code first" vs. "contract first". So for "external services" we should recommend to use an OpenAPI contract whereas if we are within a homogenous Java dominated IT landscape the "contract first" approach can be a nice opportunity/alternative (esp. when combined with our service-client).

amarinso commented 3 years ago

Since I'm now evaluating GraphQL on my current customer and Netflix just released their GraphQL framework for Spring... I wonder if it could be a viable alternative...

I haven't really seen many adoption on Enterprise projects, and I see it some bits already deprecated on my-thai-star but it seems a good fit for Agile development because of the speed you get when starting the application.

hohwille commented 3 years ago

@amarinso thanks for your feedback and suggestion. We should at least have some PoV on it. I see the great flexibility as a big pro while the great complexity is definetly a con.

hohwille commented 3 years ago

Wasn't GraphQL demonstrated in MTS once? IMHO GraphQL is kind of overcomplicating things. The problem is how people are dealing with relations. The design flaw starts with JPA and how relations are addressed in entities. As a result we have to somehow address this more specificly in TOs and REST APIs. This turned out inflexible in some projects and as a result GraphQL was introduced that IMHO goes from the one extreme to the other - but just my personal PoV. Using graph databases and Links instead of direct relations was a real eye-opener to me. With HTTP2 and now even HTTP3 based on QUIC instead of TCP (https://en.wikipedia.org/wiki/HTTP/3) round-trips will have minimal overhead and therefore you will become lazy loading in the client in the future. When using Link for relations that can be serialized as ID but allows lazy loading on client and server very easily. This has already started with reactive programming anyhow. So my personal vision is that things like GraphQL will not become the next big thing.