Problem to Solve
At work, I inherited ownership of a (legacy) very large web application (that spans multiple scrum teams and dev teams). One constant pain-point of the current large app, is that whenever one of the scrum teams updates their respective area of the application, that team has to deploy the entire app. One thing we started doing to alleviate this, is having teams create their new functionality outside of the large app, and then, just have a page inside the large app that makes an ajax call to the new app and simply injects the HTML into the large app. That way the team can just deploy the new smaller app when making changes without having to deploy the entire large application (that spans other teams).
The Good news
We currently thinking about re-writing/redesigning the large application, and one of my goals from a development perspective, is to organize it into smaller applications/code-bases, so that each team can deploy their code without having to deploy a large app that spans multiple teams. One way I plan to achieve this is to leverage multiple services to fetch data. So that would introduce one layer of separation.
From client-side perspective, one of the technologies that I am leaning heavily towards is Angular 2, especially for the separation of concerns that Angular 2 offers (components, templates, directives, etc.). I understand that I can break up an Angular 2 application into features, components, etc., but, I believe, in the end all of those still have to live within one application/code-base that all get deployed out together. Is there a way in Angular 2 to breakup a large portal/suite into smaller apps, and have the apps interact with one another. For example, maybe one shell app can be shared (for layout and navigation), but, each area of the portal/suite can be broken up into smaller apps?
Any thoughts on best ways to approach/structure this from an Angular 2 perspective are greatly appreciated. Also, if this is definitively, not possible from an Angular 2, perspective, that would also be helpful information.
Thanks in advance!
I'll try to help from multiple point of views.
Think about using Angular components as Custom Elements with “Angular Elements” - check this out: https://medium.com/vincent-ogloblinsky/export-angular-components-as-custom-elements-with-angular-elements-a2a0bfcd7f8a
If this approach doesn't fit your needs and you can only serve only one angular application, try:
If some of the application pages can be open in a different tab and leave independently there - think about splitting this huge app into smaller, modular angular application. The user doesn't have to notice the differences. if you want to use the same url for all tabs - serve the application from a reverse proxy.
If no external tabs in the flow, then you probably cant split the angular application into smaller apps, but you can build the app in a modular structure so each team takes a different application context (separate feature file) and one team will take the "shared" and "core" entities. Each team can have a separate branch with a team only privileges, and only the FE Lead can approve the PR into the master.
Another option which i haven't tried, is to split the features code into different repos - but in this way you'll have to invest in some pre-compiling scripts that can pull the code from each repo before starting the app.
If there is some server side logic in here - export to different microservices.
I see that you mentioned some HTML injection - i'm not sure how you plan to do it, but consider using a template engine.
Related
This question already has answers here:
AngularJS 1.4 --> Angular 9 migration vs bigbang rewrite [duplicate]
(2 answers)
Closed 2 years ago.
I have done a ton of research and haven't found anything that has helped me decide what will be the best route (vertical slicing, horizontal slicing, or just a complete rewrite). I am working on a very LARGE program that is very ugly with no comments and need to migrate it over to Angular 8 if possible or at least up to Angular 7. A lot seem to recommend https://angular.io/guide/upgrade however, they don't help too much in migrating to 1.5 first. Does anybody have experience with a large scale migration? Currently, the program is not being used so downtime is no issue.
It doesn't seem like it at first, but a re-write is usually a more cost effective solution than an upgrade. It seems like upgrade would be the fastest time to re-deployment but in my experience if you did the two side-by-side you might find the times similar, except that the migration deployment will have to be all or nothing, where as a re-write means you can deploy with reduced functionality and build up the feature.
More importantly, the on-going maintenance of an upgraded site becomes exponentially harder/time consuming. You're really applying band-aides over the top of previous patches and fixes.
There are new concepts, better native support for directives and controls that we used to use 3rd parties for or roll own own, and it's an entirely new language to understand. Take this opportunity to wipe the slate clean of your solution's technical debt.
Rewrite - Hybrid
Do you need to deploy eveything in one go? Are you interested in Re-Branding?
One thing the Microsoft have done well in the past is the hybrid roll-out of their Preview portals.
The best case study IMO is the Azure Portal.
A few years ago we had a pretty fully featured portal interface for managing Azure assets. This would later become known as the Classic Portal when they started work on an entirely new user experience.
At first release the menu system was largely complete, we could navigate most assets in the new portal but when you came to features that had not been redesigned yet the link took you back to the Classic Portal.
So you could do the same, have the two user interfaces deployed to different URLs, start by making sure the authentication and navigation is largely complete but make all links take the user back to the original interface. Then feature by feature, implement the new interface, but because you can't control everything, keep a button or link on each page that takes the user back to the original implementation until your regression testing confirms that you have reached feature parity.
That is another key take-away from the MS Hybrid approach, significant change like this WILL annoy your users. So while you are in transition, allow the user to choose when they themselves migrate over. Initially MS achieved this at login, the user could login at either of the main urls, and based on your profile you would be redirected to the portal of your choice.
The last step is to restrict access to features in the old interface, by making the navigation and links in the old portal navigate directly into the new interface.
- or less intrusive, add an 'end of life' banner in each page that you have compelted the re-write on in the old site.
Do not confuse this with the Preview Mode in Office 365, the Azure Preview Portal was a ground-up re-write and is still in progress. There are many licensing operations that I still use the Classic Portal for as I still manage some Classic Only azure assets that have not yet been re-deployed.
I would consider the following issues when choosing between Migration/Upgrade and a straight up re-write:
Migrate to AngularJS 1.5 first
This operation is only marginally easier than the upgrade to Angular2+. All of the arguments below apply equally to this process as they do the next upgrade.
One of the reasons to goto 1.5 first is to escape the legacy dependencies that do not have a simple direct upgrade to 2+.
During the upgrade to 1.5 you should consider implementing Component based architecture (if the current code does not already do so)
A key element of components is less configuration and simplifed design, so read this as less to upgrade, less that can go wrong
Components are of course more closely aligned with current Angular implementations, if you do not yet use AngularJS Components, that might be a good iterim step to understand before learning Angular 2+
No Comments
This is a bigger red flag than you think. If the code base is not documented then any sort of maintenance becomes incrementally harder as each time the code must be re-read and re-interpreted before you can affect change.
So if a migration is on the cards, where talking about every line of code at some point needed to be re-read and understood to make sure that it works correctly in the
AngularJS 1+ => Angular2+
While some of the core frameworks and 3rd party libraries can be migrated, most controller javascript files cannot be simply migrated to typescript without a fair amount of effort. It's pretty common in javascript to cut a lot of corners in terms of type definitions and locations of definitions that mean after migration you will spend a lot of time going back through most javascript files one method at a time.
Very large
This is a strong candidate for automation or migration but ultimately it means that the total surface area to test, debug and re-design is also very-large. If the initial migration does not compile, it could be a long road of tweaking before you can get the user interface up so you can start interface testing.
I am currently working on the frontend of one of our company's products, built in AngularJS.
Up until now the software was written specifically for one client, but now we have to make changes to accommodate change requests for a different client.
To do so we need to split the core functionality of the product and the changes each client needs. In other words we need to split the software into a main product and then each client has their own sub-project.
The main product will cover 95%+ of the functionality each client requires. The per client (project) changes will be fairly small overall.
Example:
The product has 5 different components.
Client 1 needs a component added (in addition to the 5 mentioned) and the new component needs to be reflected in the menu.
Client 2 needs the software to support RTL and also needs to make changes to one of the existing components.
How can I split up the existing codebase to, in essence create slightly different versions of the software for each client?
The catch is that the code for all clients has to be stored in the same GIT repository. The deployment process however can be on a per client basis.
Any suggestions on what I can do to make the split as painless and as maintainable as possible?
You can modularise these components and make them load via a setting file, therefore each client can have separate variations of functionality enabled.
Are these frontend clients going to talk with your company's core API or are you going to deploy those separately too? I mean if there's a core API you can authenticate requests on client basis and restrict/enable functionality easily. You could store these configurations on the database level in this case.
I have built an angular front end that will be served by a Zend Framework 2 back end. Now I am wondering, do I integrate my angular project into ZF2 OR should I simply keep it as a stand alone entity outside of ZF2?
Originally I was building this as an integrated entity and because my angular developer does not use ZF2, we decided to simply make a vanilla version of the front end APP for ease of use so that he could work on it without having to struggle with ZF2.
Now that the app is mostly built, I am wondering if it is necessary at all to integrate it?
What are the advantages and disadvantages?
My guess is having completely separated projects allows you to completely rebuild one without touching a line of the other in case an evolution is not possible using either ZF2 or Angular and you need to switch to something else.
If you are hosting on a PAAS, you then have to pay for two instances. Lets say you host on Heroku, you may need to have an environment for your front (lets say 3 dynos) + ssl (£20/months) and the same for the backend (£20 for ssl as well). Additionally, you will need two ssl certificates (£10/year for the cheaper, but can be expensive with EV certificates).
Finally, you may have trouble with CORS with separated projects, which won't exist if both are merged in a single project.
My previous statements lead to say one single project can be good, but I guess it is a very delicate decision!
How is it possible to have folder in controller?
For example this scenario: We have multiples clients and each clients might have different package that share the common controller or different controller based on their own request. So I was thinking to separate them by directory in the controller.
Any Expert in Architecture can help this?
This is probably possible, but is certainly not the way you should do things with Cake (or MVC in general, probably).
I suggest that you have a separate app for each client. If you have any specific questions regarding this, or would like to add more information to your question about what you're trying to do, I can try to give you a more in-depth answer.
Without knowing more it is hard to say.
I assume you have one app that is used by multiple clients through subdomains or something else to make a difference between who is using it.
You can have a plugin per client that extends the base apps controllers as needed. You also can have different models and views then. Use routes to make the different named controllers match always the same URLno matter what client is logged in.
I would prefer a one app solution over multiple applications because it reduces the maintenance overhead a lot. But if you want to for multiple apps I would build the core of the application that is shared by all sites as a plugin itself. Using git and submodules you can then even control what version of the core module each site is using.
So, yes, this is probably 1000th question on the subject. However, my question is somewhat different from others that were asked about this, so please bear with me:
I am looking to develop a single mobile-app that targets the three/four popular and/or growing mobile platforms (Iphone, Android, WinPhone7, RIM). This application is an extension of an existing SaaS system that my startup currently offers. This mobile-app would provide a quick-and-simple way to view up-to-date status & chart & report information for the data that SaaS application collects. Connection to the internet is required 100%. No data entry besides username/password. App is very simple with 5-6 "pages".
In phase 1, all that would need to be supported is for user to log in, get to see current status of his data stored in the cloud, get access to a few live reports
In phase 2, I'd like to be able to offer push-notification of certain key events from my servers in the cloud
My goals are:
1) The back-end processing that generates data for reports is already written in ASP.NET MVC2. I want to re-use it. It can be exposed as either a WCF service or published on a mobile-friendly website
2) I'd like to be able to deploy the patches faster than through the official app-stores/marketplaces.
3) I cannot afford to spend a lot of resources to target three-four proprietary platforms, for an app that is auxiliary to the vertical purpose of the business. I want to develop it once for all 3-4 platforms.
4) I do not have access, nor do I want to purchase a Macbook
5) I do want to deploy thru the vendor-specific application marketplaces
6) I'd like to stay way from proprietary languages/frameworks/lock-ins
Sounds like what I need is a shell around a mobile-friendly site that can be packaged as an app. Are there existing products that can make it REAL EASY for me to do so? Will doing so, preclude me from doing push notifications in phase 2?
Can anyone recommend a "shell" product that would make a wrapper around the website as well as Javascript library that would look the best across all 4 platforms. I've seen the names like Jqtouch, Jquery Mobile, etc... but not sure which ones are better for what I need.
Do I need PhoneGap? I am not 100% sure here. Can PhoneGap use online-only html/javascript pages to translate into native code or must html/javascript files be distributed with the application? I'd rather have the website itself drive the UI completely, as I can keep changing the website without various version approval processes from vendor market-stores.
Thank you for help
I don’t think you need Phonegap after reading about your project goals. You might consider a Web App instead of a native one if you 1) dont want to buy a mac (required for iOS even tho you can compile it in the cloud: https://build.phonegap.com/), and 2) want to apply and deploy updates anytime without going thru those platform independent marketplaces and approval processes.
jQuery Mobile would be an excellent choice, currently (at this very moment) in Alpha 3 but a very stable one and you can deploy your system on any of those platforms. Note that if you focus your efforts in a Web App you can’t target the second phase you mentioned: Push Notifications.
If you decide going Native, then Push Notifications services can be deployed into your Phonegap project once you setup the proper web services and certificates (take a look # http://easyapns.com);
..and one quick note, the idea of phonegap is that all resources (html, js, images. etc) have to be distributed locally within the app and then getting online data (like reports, etc) using JSON from another web service, and that’s another easy task to accomplish. Phonegap DOES NOT compile your HTML files into native code (ObjectiveC or Java), it just load your Web App into a UIWebKit component at run time (in the case of an iOS app)
Another alternative could be using Titanium - http://www.appcelerator.com but this approach is more javascript oriented and your final app looks much more native. (not HTMLs here so I think thats a drawback for you)
Hope it helps :)