resthub-jpa-backbonejs-multi-archetype package issue

[manos]

The services defined in the contract module naturally use the DTO
classes instead of the model entities defined in the core module. Both
modules however use the same package for service interfaces. If you
try to create service interfaces in the core module using model
classes in generics, you get boundary conflicts with the DTOs used in
the contract module.

So for implementing a 3 tier CRUD service i had to delete the service
interfaces from the contract module and redefine them in the core
module extending CrudService<MyModelClass, ID>.

Am I missing something here or should the contract packages be
renamed?

Manos

[Sébastien Deleuze]

Hi,

Thanks for your interesting feedbacks. You're right multi-module archetype need some improvements and additional guidance. We will give you a complete answer monday.

Regards

Manos

--

[Brian]

So, we've updated our multi-modules archetypes right before the 2.0.0 release.

You were confused by these archetypes because their intent weren't clear.

At first, we simplified the multi-modules archetypes and removed the useless parts.

Then we have to solve the original problem by creating examples and documenting our intents.

For now, we identified two intents in some applications, related to that kind of multi-modules projects.

"public API"-driven project

Let's say you want to build a public REST API, used by many clients (browsers, native apps, servers...).

So you definitely want to add features to your backend without modifying your API, and vice versa.

You should consider implementing in the core module:

• model
• services/repositories implementations
• controllers implementations 

In the contract module, you'll find:

• DTOs (with serialization annotations, but no persistence annotations at all!)
  
• Controllers interfaces (that (de)serialize DTOs only!)

The goal here is to decouple your backend from your public API. You'll have to map models and DTOs using modelmapper (see RESThub documentation).

RPC-driven projects

This is a different use case.

Let's say you want to implement RPC-calls between services hosted on your platform.

Exposing models in the contract module is not a big problem here; but you really want to avoir dependency graphs nightmares. The contract module is the dependency you want to add to RPC clients to quickly build efficient communication channels between remote services.

Here, you definitely want to have "the RESThub way" with an efficient service->RPC->contract->repository stack.

Does your application fit one of those scenarios?

Cheers,

-- Brian

--