On Sat, Jul 25, 2015 at 3:55 PM, Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
You may be mixing "business logic" with tapestry's page/component classes. > No, that's not the case actually. > You shouldn't put any business logic to the presentation layer > (which is TMLs and page/component java classes). > Even if business logic is completely moved to service layer, that doesn't solve the problem of exposing other potential developers to Tapestry (which is undesired). Using Angular + RESTEasy does look like a good solution here (I was thinking of something similar). > All logic should be extracted to tapestry services, or even EJB as in the > JumpStart examples: > http://jumpstart.doublenegative.com.au/jumpstart/examples/state/atejb > > If you don't like tapestry services nor EJB, then nothing really stops you > from wrapping your tapestry services or EJBs with REST API and creating > client API > that will be consumed from tapestry page/component classes. > > With this approach you may develop backend separately from backend. > > If you're going to deploy your app as a single monolith app you > can move your BL to tapestry services and that's it -- you don't need to > create > any API between them if they live in the same JVM. > > You may even package you services in a separate JAR containing tapestry > modules > and add these JARs to your frontend app. > > If you want to deploy them separately -- you obviously need some > communication protocol, > like REST or EJB. In this case you may continue using tapestry+tynamo > resteasy to implement your services, > but it could be any other technology stack, like Spring Boot or anything > else. > > I'd also advise you to think of splitting your app not by layers (frontend > vs. business logic), > but using functional aspects, each function would include both frontend & > backend and be sufficient by itself. > For example, you may extract part of your pages into a separate tapestry > app and run it next to your "main" app, > maybe even in the same JVM, or package these apps all together during build > time into one monolith. > > As you see there are many options. > You need to decide how are you going to deploy resulting app(s). > > General advise here may be that one deployable unit should have one > dedicated team of developers > who are responsible for that unit. > > Unless this is a really simple service that once developed & deployed stays > untouched, > otherwise I don't think you'll have any benefits from delegating your > workload. > > On Sat, Jul 25, 2015 at 3:16 PM, Ilya Obshadko <ilya.obsha...@gmail.com> > wrote: > > > At this moment, my own project has grown big enough, so I've started to > > consider delegating various parts of the workload to others. > > > > However, there is one particular issue: when the whole thing is built on > > Tapestry, any person involved should understand the framework, and it's > not > > possible to isolate frontend tasks from backend ones (because all the > > Tapestry "endpoints" are in fact event handlers and all AJAX requests are > > handled through usual event processing chain). > > > > One obvious solution is Tapestry+RestEASY (or any other similar REST > > module) and moving all controller logic to JS on the frontend and to REST > > handlers on the backend. This way pages/components are becoming just > > "stubs" that initialize required HTML/JS. > > > > Any other thoughts maybe? > > > > -- > > Ilya Obshadko > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- Ilya Obshadko
