> By "we" I mean everyone involved in the Traffic Control project.
Ah. Well, that's sort of what I was hoping to find out with this discussion. > Is it not possible to add all of the features you are referring to in > this email to the existing Traffic Portal code? Oh, of course it's _possible_. It's just that the existing Traffic Portal code is using a dozen deprecated frameworks and has fragile external dependencies. The migration to a newer version of Angular _should_ happen at some point anyway, and as Jeremy mentioned there is no simple upgrade path from AngularJS to Angular because they aren't the same thing, really. And because there's no existing Self-Service scaffold to build on, it's my opinion that implementing it in the existing Traffic Portal would be the same amount of work (actually more imo, but that's certainly up for debate) as writing it fresh in a more modern way. Doing so will also provide the benefit of easing transition between AngularJS TP and Angular TP because a foundation for the latter will already exist. So I think that doing it this way is roughly the same amount of work _now_ and saves us potentially a ton of work _later_. > I'm just wondering why we (Traffic Control project) need another > re-write of an existing component. That's a fair point, but so far it _isn't_ a re-write. The idea is implementing functionality that the existing Traffic Portal doesn't have - and wasn't designed for - and I think that at some point in the future the newer TP should "eat" the old one so that we wind up with one UI. But even if everyone else hates that idea, I still think it's worthwhile to go about implementing Self-Service like this from the ground-up because it'll make corner cases where advanced TP functionality peeks through easier to catch (because it won't exist yet :P). Plus have I mentioned that writing, reading, and testing Typescript is way easier than Javascript? @Jonathan well, the hope is that other devs will want to work on this, but I can't guarantee that. ________________________________________ From: Gray, Jonathan <[email protected]> Sent: Wednesday, April 10, 2019 9:36 AM To: [email protected] Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ Self-Service Depends on if it's under active development by more than one person imho. I have an experimental PR out there for a sample graphql API, but I don't really expect anyone to merge it because it doesn't integrate with the solution. If something is a collaborative effort by the community I think it warrants a feature branch, but something being developed by a single developer is easier to just keep in a fork with an experimental PR (maybe even a new shiny draft PR). I make that distinction just because our mainline git branches come with overhead to maintain/merge/review and it removes the single contributors ability to rebase and force-push. Jonathan G On 4/10/19, 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. >
