Trustroots Technical Debt

[mrkvon]

It may be worth specifying what it means when we say that

Trustroots has 7 years of technical debt

AFAIK Trustroots is built on top of MEAN stack which has not been maintained since 2016.

In practice this means:

• Frontend is based on AngularJS, a legacy framework now superseded by (substantially different) Angular.io, and barely anybody uses it (i believe). The React in Trustroots at the moment is mostly just Presentation Components on top of the AngularJS. AngularJS typically takes care of routing, state management, ...; and it should be migrated to React fully, but has not happened for 2+ years now. (i haven't checked the state of the progress recently though) - more details: [Overview] React migration Trustroots/trustroots#1334 and in the framework refactor project
• the codebase has mixed backend and frontend code together in modules. These days i'd expect separate backend (API) and frontend (app) codebases. Probably depends on preference.

So this (and possibly more) is the technical debt that we're dragging with us when we decide to build on top of Trustroots code. Of course with the debt we're also taking a lot of benefits. Well tested codebase, statistics, beautiful UI (user interface) and good UX (user experience).

If the contributors of this repository decide to tackle the technical debt, it would be worth sharing it with the upstream - the original codebase. However, MIT licensed code (Trustroots) may not be able to accept code licensed by AGPL (this repository). However @mariha was mentioning to me today that TR people would take it... (?)

[weex]

docs/Development.md states that Trustroots was seeded initially with MEAN.js and looking at the components all are actively developed except for the E, ExpressJS which hasn't itself had any updates for 2.5 years.

I also noted during install that npm reported hundreds of outdated packages, tens with security issues so I would add security to the tech debt overhang.

As for the licensing, the issue isn't so much that Trustroots wouldn't accept some code from this repo if it were AGPL'd but that Trustroots would need permission from each contributor, granted there are few currently but the hope would be more over time, similar to what libzmq needs for its own relicensing effort, for inclusion.

[lennartvanlaake]

I think technical debt is also a matter of perspective. If you are a new community not inteserted in many of the features Trustroots has (probably Circles don't make much sense if you are running 1 instance per community), then those features can be seen as "technical debt", unnecessary code that doesn't do anything, from the perspective of that community, while those features are perfeclty valid for Trustroots itself.

So for me "technical debt" from the Fairtravellers perspective would mean all the stuff that is in the code base slowing development down, that is not strictly necessary for the purposes of Fairtravellers. Maybe "technical debt" isn't the right word for it, but I'm struggeling to find a better one to express this broader issue.

[mrkvon]

[all the] components [of MEAN] are actively developed except for the E, ExpressJS

It's the AngularJS, unfortunately, whose end of support is scheduled at December 31 2021.

[weex]

I was going to ask if that's a hard end-of-support but it looks like it is as AngularJS is recommending a commercial vendor for support after that point. @mrkvon Do you think 1.8.x will see security updates after that time?

[weex]

Also, does it make sense to split the Express and AngularJS debt into different issues on the idea that they'd be solved separately?

[mariha]

Here is an overview of React migration from TR: Trustroots#1334

[mrkvon]

@weex

Do you think 1.8.x will see security updates after that time?

Hard to say. I don't know. I opened an issue Trustroots#2436 letting them know about this. AngularJS is probably so stable that this won't be a concern for further months or years to come. But eventually it will have to be migrated away from.

does it make sense to split the Express and AngularJS debt into different issues?

I looked around and Express.js still seems to be a standard for writing REST APIs in Javascript. I can see they're (slowly) working on a version 5.x, too (currently alpha). Perhaps they didn't release any new version because Express is so stable? 🙂 I wouldn't even know what to replace Express with. Maybe it's not a technical debt after all... idk.

[simison]

Hi @mrkvon ! Thanks for highlighting the topic to me. :-)

Few notes, hope you find these helpful for your decision making:

Trustroots is built on top of MEAN stack which has not been maintained since 2016.

There are two separate things; MEAN (MongoDB/Express/Angular/Node.js) stack which is all fine and healthy, and MEAN.js boiletplate based on that stack. That's the initial boilerplate we used indeed.

I think the boilerplate is irrelevant for what Trustroots is today though, as we've departed in so many ways from the original setup done in 2013. AngularJs is the really problematic part as you point out, and React migration is our way to solve it. Can't get finished fast enough. :-)

I don't really see ExpressJS an issue myself, or pressure to upgrade/switch. There are several more-or-less compatible alternatives so switching should go fairly smoothly if ever needed. Happy to be pointed wrong on this of course. :-)

I listed further framework level technical debt in an issue — lemme know if I missed any!

Then there's the UX debt, which I think mostly revolves around our information architecture (headers, sidebars, navigation, headers, footers and things like that).

the codebase has mixed backend and frontend code together in modules. These days i'd expect separate backend (API) and frontend (app) codebases. Probably depends on preference.

While server/client code could definetely be further apart, I disagree that separate repos are somehow more modern compared to monorepo. I'd argue monorepo tooling (Lerna, Yarn workspaces, NPM) has come a long way in recent years so things are in fact just getting better. I personally wouldn't mind to bring also native mobile codebase to same monorepo. Single repository provides better developer experience in my opinion. That said, more flexibility to run the API and client separately would be welcome and wouldn't be very big effort to do.

Hope this helps!