future of OFBiz: REST is essential.

[Hans Bakker]

Good morning, fellow developers.

It is now almost 15 years ago i started with OFBiz. I always followed
new technology developments and used them when they became usable in a
production environment. That is why i joined OFBiz early. I also
proposed years ago to go from svn to git that now finally is approved
for OFBiz. I also proposed to replace the OFBiz framework with
Moqui.org, yes I know a much bigger change but believe me, that will
also happen one time for you.

We now support Moqui for about a year and the main reason we switched
over is the excellent REST interface Moqui has. This allows you to have
a user interface fully independent from Moqui, yes a website or a mobile
application just using the data from Moqui via REST. All screen
rendering is now done with for example the vue.js framework using
javascript in the client, not using ftl at all, improving the user
interface experience dramatically. So all templates and the rendering is
in the client making it completely static and can be loaded from cdn
networks.

My advise? If you want to extend the life of OFBiz implement a REST
interface quickly...or copy it over from Moqui, no problem, the license
allows it.

Regards,

Hans Bakker,
CEO antwebsystems.com

[Michael Brohl-3]

Hi Hans,

several people in the community are already working on REST
implementations, I'm sure we will have one soon.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 29.01.19 um 06:12 schrieb Hans Bakker:

> Good morning, fellow developers.
>
> It is now almost 15 years ago i started with OFBiz. I always followed
> new technology developments and used them when they became usable in a
> production environment. That is why i joined OFBiz early. I also
> proposed years ago to go from svn to git that now finally is approved
> for OFBiz. I also proposed to replace the OFBiz framework with
> Moqui.org, yes I know a much bigger change but believe me, that will
> also happen one time for you.
>
> We now support Moqui for about a year and the main reason we switched
> over is the excellent REST interface Moqui has. This allows you to
> have a user interface fully independent from Moqui, yes a website or a
> mobile application just using the data from Moqui via REST. All screen
> rendering is now done with for example the vue.js framework using
> javascript in the client, not using ftl at all, improving the user
> interface experience dramatically. So all templates and the rendering
> is in the client making it completely static and can be loaded from
> cdn networks.
>
> My advise? If you want to extend the life of OFBiz implement a REST
> interface quickly...or copy it over from Moqui, no problem, the
> license allows it.
>
> Regards,
>
> Hans Bakker,
> CEO antwebsystems.com
>

[Mathieu Lirzin]

Hello Hans,

Hans Bakker <[hidden email]> writes:

> It is now almost 15 years ago i started with OFBiz. I always followed
> new technology developments and used them when they became usable in a
> production environment. That is why i joined OFBiz early. I also
> proposed years ago to go from svn to git that now finally is approved
> for OFBiz. I also proposed to replace the OFBiz framework with
> Moqui.org, yes I know a much bigger change but believe me, that will
> also happen one time for you.

I don't think this kind of communication style is very helpful in
general.  This sounds a lot like you are saying to the rest of us “You
are doing it wrong, I know better!”.

> We now support Moqui for about a year and the main reason we switched
> over is the excellent REST interface Moqui has. This allows you to
> have a user interface fully independent from Moqui, yes a website or a
> mobile application just using the data from Moqui via REST. All screen
> rendering is now done with for example the vue.js framework using
> javascript in the client, not using ftl at all, improving the user
> interface experience dramatically. So all templates and the rendering
> is in the client making it completely static and can be loaded from
> cdn networks.

This is indeed highly desirable to let other interfaces like Single Page
Applications (SPA) consume the data and manipulate the services OFBiz
provides via a RESTlike interface.

On the SPA side, I personally encourage you to look at frameworks based
on what is often referred as the “Elm Architecture” [1] (React/Redux,
Re-agent, Elm, …) for the reason that are based on a “one way data flow”
and embraces functional programming.  They differs from frameworks like
Angular or Vue which has a “two way data-binding” which mean that they
are inherently more complex and harder to reason about.

> My advise? If you want to extend the life of OFBiz implement a REST
> interface quickly...or copy it over from Moqui, no problem, the
> license allows it.

Could you present the design of Moqui REST support (architecture,
advantages, drawbacks, limitations, …) and give some pointers to the
implementation?

Additionally what would be your recommended strategy to port this work?
Are you willing to do the work?

Thanks.

[1] https://guide.elm-lang.org/architecture/

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Hans Bakker]

see my answer inline...

On 01/29/2019 04:01 PM, Mathieu Lirzin wrote:

> Hello Hans,
>
> Hans Bakker <[hidden email]> writes:
>
>> It is now almost 15 years ago i started with OFBiz. I always followed
>> new technology developments and used them when they became usable in a
>> production environment. That is why i joined OFBiz early. I also
>> proposed years ago to go from svn to git that now finally is approved
>> for OFBiz. I also proposed to replace the OFBiz framework with
>> Moqui.org, yes I know a much bigger change but believe me, that will
>> also happen one time for you.
> I don't think this kind of communication style is very helpful in
> general.  This sounds a lot like you are saying to the rest of us “You
> are doing it wrong, I know better!”.

I just want to indicate that the OFBiz community is going to run behind
in the technology developments so from my point of view too conservative.

>> We now support Moqui for about a year and the main reason we switched
>> over is the excellent REST interface Moqui has. This allows you to
>> have a user interface fully independent from Moqui, yes a website or a
>> mobile application just using the data from Moqui via REST. All screen
>> rendering is now done with for example the vue.js framework using
>> javascript in the client, not using ftl at all, improving the user
>> interface experience dramatically. So all templates and the .rendering
>> is in the client making it completely static and can be loaded from
>> cdn networks.
> This is indeed highly desirable to let other interfaces like Single Page
> Applications (SPA) consume the data and manipulate the services OFBiz
> provides via a RESTlike interface.
>
> On the SPA side, I personally encourage you to look at frameworks based
> on what is often referred as the “Elm Architecture” [1] (React/Redux,
> Re-agent, Elm, …) for the reason that are based on a “one way data flow”
> and embraces functional programming.  They differs from frameworks like
> Angular or Vue which has a “two way data-binding” which mean that they
> are inherently more complex and harder to reason about.

choosing a use rinterface is an other subject, but not possible without
a proper rest interface

>> My advise? If you want to extend the life of OFBiz implement a REST
>> interface quickly...or copy it over from Moqui, no problem, the
>> license allows it.
> Could you present the design of Moqui REST support (architecture,
> advantages, drawbacks, limitations, …) and give some pointers to the
> implementation?
>
> Additionally what would be your recommended strategy to port this work?
> Are you willing to do the work?
>
> Thanks.
>
> [1] https://guide.elm-lang.org/architecture/
>

We just support existing OFBiz installations For new installations we
use Moqui.
I just finished a proof of concept for a native Android/IOS app using
Moqui REST. For OFBiz i intended to make it work too but that proved to
be too difficult without REST.

If there would be an OFBiz REST API then it is feasibel to write UI
applications which both work on OFBiz and Moqui because the basic
functionality from an API point of view is not that different.

Thanks for your reply..

Regards,Hans Bakker
CEO antwebsystems.com

[Hans Bakker-2]

Hi Michael,

i checked https://issues.apache.org/jira/browse/OFBIZ-4274 which started
2011,  lets hope you are right?

Regards,
Hans
antwebsystems.com

On 01/29/2019 03:47 PM, Michael Brohl wrote:

> Hi Hans,
>
> several people in the community are already working on REST
> implementations, I'm sure we will have one soon.
>
> Thanks,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 29.01.19 um 06:12 schrieb Hans Bakker:
>> Good morning, fellow developers.
>>
>> It is now almost 15 years ago i started with OFBiz. I always followed
>> new technology developments and used them when they became usable in
>> a production environment. That is why i joined OFBiz early. I also
>> proposed years ago to go from svn to git that now finally is approved
>> for OFBiz. I also proposed to replace the OFBiz framework with
>> Moqui.org, yes I know a much bigger change but believe me, that will
>> also happen one time for you.
>>
>> We now support Moqui for about a year and the main reason we switched
>> over is the excellent REST interface Moqui has. This allows you to
>> have a user interface fully independent from Moqui, yes a website or
>> a mobile application just using the data from Moqui via REST. All
>> screen rendering is now done with for example the vue.js framework
>> using javascript in the client, not using ftl at all, improving the
>> user interface experience dramatically. So all templates and the
>> rendering is in the client making it completely static and can be
>> loaded from cdn networks.
>>
>> My advise? If you want to extend the life of OFBiz implement a REST
>> interface quickly...or copy it over from Moqui, no problem, the
>> license allows it.
>>
>> Regards,
>>
>> Hans Bakker,
>> CEO antwebsystems.com
>>
>