Does AMP make application harder to maintain? Is it worth re-implementing an existing application using AMP? When do you decide you need AMP as oppose to simple classes and packages?
Thiese were some of the questions and doubts that comes up during discussions on AMP. However, using AMP is really not an either or choice. You can keep using classes and packages. What you need to be aware of are the new programming facilities, the jsx3.$ functions. Especially the Asynchronous Programming Utilities
In Short, Why use AMP? Well ..
> An application's main definition XML in an AMP application can be made up of several source code files that are developped separately and then assembled together. Saving time since it is not necessary to recompose the complete application, when making a single change, but only the file that contains the change.
> There is a difference between complexity and maintainability. Making the assumption that the complexity of the underlying framework will lead to higher cost in maintenance is too simplistic.
> In the old way, coordinating the integration of a large complex application becomes a major task when everything you do may affect someone else.
Builder and AMP integration :
1. Creating AMP based application is a distributed process by nature. AMP based application are best suited for a large scale development with large number of team members. The fact that you cannot see the overall application when you work on one module should not affect the developer since he will be focused only on his module.
2. When developing using AMP, you can continue to develop GUI prototypes with Builder, which is essentially what the visual environment is good at.
> An investment in time and resource must be made to convert an application to AMP based design. There is definitely effort needed to design the proper extension point abstractions.
1. However, when the conversion work is done, the application becomes much easier to add functionality to and maintain than it would ever be using a different architectural design
2. In the case of GI builder, we're now able to disable or add new functionality into Builder without fear of inadvertently breaking the other functionalities within GI Builder.
3. The performance improvement for GI Builder over HTTP is probably at least double of what it was before.
> The architectural constraints that AMP imposes actually makes code easier to maintain and less brittle. For example, interactions between plug-ins are well defined and limited in AMP, which encourages loosely coupled application components. When using AMP correctly, spaghetti code is must less likely to occur and would never span plug-ins, greatly reducing developer burden in maintaining not just their own code but also those of others.
> Performance improvement using AMP architecture comes from
1. Forcing good design and coding practice in a asychronous environment.
2. Defining publish / subscribe interface that allow one to many communications and fully loosely coupled module
3. Allowing feature/extension based load (plug-in) and play, which can lead to smaller run-time application size.
> The well defined modular interface in AMP means that what was not possible before can now be done, such as : integrating the application without some of it parts, adding or removing parts and running a partially complete application.
