decoupling business logic and frontend

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

decoupling business logic and frontend

Ilya Obshadko-2
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
Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

duymap
Hi,

I suggest Tapestry+RestEasy+AngularJS. AngularJS is powerful MVC font-end
framework. Moreover you should research to try integrate bower grunt in
your project. Bower is used to pull necessary third party js go with
angular and grunt is used for building css based on sass.

So the final project structure should be: Tapestry+RestEasy+AnguarJS +
Bower + Grunt and Gradle.

Here is the link about demo to integrate angularjs into tapestry + restful
web service: https://github.com/ffacon/tapestry5-angular-demo

Hopefully it can help.

Duy


On Sat, Jul 25, 2015 at 7:16 PM, Ilya Obshadko <[hidden email]>
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
>



--
Chung Khánh Duy
Project Support Manager
Formos
Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

Dmitry Gusev
In reply to this post by Ilya Obshadko-2
Hi,

You may be mixing "business logic" with tapestry's page/component classes.

You shouldn't put any business logic to the presentation layer
(which is TMLs and page/component java classes).

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 <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

Ilya Obshadko-2
In reply to this post by duymap
Thanks Chung,

That seems very close to the solution I was looking for.

On Sat, Jul 25, 2015 at 3:54 PM, Chung Khanh Duy <
[hidden email]> wrote:

> Hi,
>
> I suggest Tapestry+RestEasy+AngularJS. AngularJS is powerful MVC font-end
> framework. Moreover you should research to try integrate bower grunt in
> your project. Bower is used to pull necessary third party js go with
> angular and grunt is used for building css based on sass.
>
> So the final project structure should be: Tapestry+RestEasy+AnguarJS +
> Bower + Grunt and Gradle.
>
> Here is the link about demo to integrate angularjs into tapestry + restful
> web service: https://github.com/ffacon/tapestry5-angular-demo
>
> Hopefully it can help.
>
> Duy
>
>
> On Sat, Jul 25, 2015 at 7:16 PM, Ilya Obshadko <[hidden email]>
> 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
> >
>
>
>
> --
> Chung Khánh Duy
> Project Support Manager
> Formos
>



--
Ilya Obshadko
Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

Ilya Obshadko-2
In reply to this post by Dmitry Gusev
On Sat, Jul 25, 2015 at 3:55 PM, Dmitry Gusev <[hidden email]>
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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

Thiago H de Paula Figueiredo
In reply to this post by Ilya Obshadko-2
Hi!

On Sat, 25 Jul 2015 09:16:30 -0300, Ilya Obshadko  
<[hidden email]> wrote:

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

I'm not sure I can agree with you. Business logic is supposed to be  
written inside Tapestry-IoC services, so people working on them only need  
to know T-IoC basics, which are very simple, so you can easily create  
tasks that don't need any knowledge at all on Tapestry-core (the web  
framework).

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: decoupling business logic and frontend

Jens Breitenstein
I go with Thiago.

We use different maven modules for our business logic and persistence classes so both maven modules are standalone using their own tests. There is no relation to Tapestry at all for these modules.

We use Tapestry services and Tapestry IOC to tie it together in our webapps

We even use these budinesslogic in non Tapestry war's e.g to support cron based jobs in parallel or reuse the backend services in different Tapestry Apps. I do not see any reason to use a remote connection, beside you have different life cycles for these modules and deployment is out of your control

Jens

Von meinem iPhone gesendet

> Am 27.07.2015 um 14:56 schrieb Thiago H de Paula Figueiredo <[hidden email]>:
>
> Hi!
>
>> On Sat, 25 Jul 2015 09:16:30 -0300, Ilya Obshadko <[hidden email]> wrote:
>>
>>
>> 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).
>
> I'm not sure I can agree with you. Business logic is supposed to be written inside Tapestry-IoC services, so people working on them only need to know T-IoC basics, which are very simple, so you can easily create tasks that don't need any knowledge at all on Tapestry-core (the web framework).
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]