Why can’t the form wizards and other self-service features be built into the existing AngularJS Traffic Portal code?
—Eric > On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <[email protected]> wrote: > > I think I agree with Chris about just using the "experimental" folder as we > always have. Then it's pretty easy to look in there and see what's > "cooking": > > experimental > - traffic_router_golang > - traffic-portal-angular7 > - traffic_ops_ruby_on_rails (just kidding :) ) > > Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences > for TP: > > 1. Admin/ops type users > 2. self-service type users > > TP works well for #1 but not really for #2. The trick is to build a UI that > works well for both OR have 2 distinct UIs. As developers, we don't like > the idea of 2 UIs as that sounds like double the UI work when something > changes. > > So we could either: > > a. make TP (angularJS) more self-service friendly > b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and > such) and focus on ds, user and tenant management and then slowly port the > rest of TP functionality into it > c. support 2 distinct UIs > > I think "b" makes sense and the effort can start (as many of our efforts > do) as "experimental" and if it gets legs maybe it does replace TP or maybe > it doesn't and it simply becomes a UI that you can use (or not use) to > solve ds/user/tenant management in a simple/self-service type way. > > Jeremy > > On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <[email protected]> wrote: > >>> Are we seriously considering totally re-writing another component? >> >> Depends how you count it. One of the most important parts of the >> previous re-write (still in progress) is the "separation of powers" >> that makes things like this relatively non-destructive and able to be >> managed in parallel. I like experimental pokes into what the future >> might hold, like this one. I'm not totally sold, but the scope isn't >> crazy. It's mostly a UI on top of the existing API. >> >> Historically, experimental or alternate components have lived in the >> main branch, but the experimental folder. That lets them be part of >> the same process as the rest of the code, ensures code reviews as they >> progress, and the CI will keep everything in license compliance. >> >> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan >> <[email protected]> wrote: >>> >>> Branching is fine with me, I doubt I have permission to create a branch >> myself, though. >>> >>> As an aside based on that: should `traffic_router_golang` also be moved >> to a branch? I think the branch idea is better than having an >> `experimental` directory. Or maybe that experiment is dead and should just >> be removed instead? The last change was 10 months ago. >>> ________________________________________ >>> From: Gray, Jonathan <[email protected]> >>> Sent: Wednesday, April 10, 2019 9:09 AM >>> To: [email protected] >>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ >> Self-Service >>> >>> Instead of merging it into master, could we merge it to a feature branch >> like `experimental/TP.rewrite` if there is a desire for collaborative >> efforts. This would allow changes to flow in without adding more code to >> our normal review processes and polluting the changelog with WIP until it's >> done and ready to be merged. As an additional bonus it provides a more >> stable development for the new work since you'd be choosing when to pay the >> merge costs of ongoing master changes. >>> >>> Jonathan G >>> >>> >>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <[email protected]> >> wrote: >>> >>> I guess that depends what you mean by "we". I personally think it's >> worthwhile, and I'll probably keep working on it until it reaches feature >> parity with the existing TP. >>> >>> I'm not saying development on the existing AngularJS-based TP should >> stop in the meantime, just that self-service be implemented separately in a >> more modern and flexible framework. Then - and only then - should we >> consider replacing the old TP with the new. Slowly, over time. The current >> TP was built for admins, so I don't think it'd actually be more work to >> implement a customer-facing interface this way than restructuring the >> existing TP to support it. >>> ________________________________________ >>> From: Hank Beatty <[email protected]> >>> Sent: Wednesday, April 10, 2019 8:38 AM >>> To: [email protected] >>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ >> Self-Service >>> >>> Hello, >>> >>> Are we seriously considering totally re-writing another component? >>> >>> -Hank >>> >>> On 4/5/19 12:09 PM, Fieck, Brennan wrote: >>>> Some of you may have heard, but about two and a half weeks ago I >> opened a Pull Request to add something to the `/experimental` directory. >> It's basically a re-implementation of Traffic Portal, which I think is >> beneficial not only because Traffic Portal wasn't designed with >> self-service in mind, but also because it cleans up a few issues on the >> development side. First of all, it uses the most recent LTS version of >> Angular, while the one on which Traffic Portal is currently based is now >> deprecated (this new version can also compile projects for Electron, which >> would make TP distributable as a standalone/mobile app). It also uses >> Typescript which compiles more cleanly to an overall smaller product, and >> is much easier to read, write and document. Remember the SCSS compiler >> issues (compass) we keep having? Angular 7 comes with a compiler at project >> init, so we never need that as an externally-provided dependency again. >> Finally, it already has unit testing and end-to-end testing working in four >> different JS engines. >>>> >>>> >>>> I'm currently looking for a reviewer ( >> https://github.com/apache/trafficcontrol/pull/3419) and you can read more >> about what's implemented there, but a short summary: >>>> >>>> >>>> * Login/authentication and API proxy >>>> * Delivery Service view with bandwidth charts >>>> * New Delivery Service creation targeted at self-service users >> with limited advanced editing options >>>> >>>> * User listing (read-only) >>>> >>>> * Preliminary HTTPS support (currently only listens on 'localhost') >>>> >>>> >>>> Plus, if I do say so myself, it all looks pretty snappy on every >> screen I could test. >>>> >>>> >>>> Feedback is also appreciated, especially concerning the "New >> Delivery Service" form. >>>> >>> >>> >>
