• 4 Posts
  • 11 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle

  • Microfrontends are a technical solution to an organizational problem, if you can get away with not doing them, you might do yourself, your coworkers and your company a big favor.

    Having said that, do you deploy this app, that you want to split into microfrontends, as a SaaS or is it more enterprisy and installed on-prem and access mainly via Desktop? If the latter, the venerable iframe might be your friend.

    Also, if you really cannot help it, you should consider building an abstraction where you consider iframes, web-components, or lazily-loaded scripts as an implementation detail.

    Source: I’m maintaining something that you’d in microfrontend term would describe as an application shell in Angular 2 since 2017. It hosts > 1000 different screens provided by > 60 dev teams ( > 450 devs) into a single user facing view. And I justified at least one years’ salary by talking my boss in 2019 out of using the approach again on a second product line (where the scope was narrower).








  • The crucial point to me, which I could not read out of your first post, nor will I implicitly assume it as a given, is that there still is a feedback loop from product development to the staff/principal level.

    I’ve been burned by a code base that was created by a principal engineer, who tossed it over for maintenance and moved on to greener pastures (still in the company though). It is more to blame on the organization, than on the engineer, but still such an experience leaves a slightly bitter taste.


  • Others have already mentioned the official documentation, which is a solid starting point. If you are jumping into a existing project, chances are that the steepness of the initial learning curve will be determined more by the choice of libraries beyond core Angular.

    You’ll certainly have to also get familiar with the API of some ready-made component library (Material and the likes), as well as probably some sort of state management (NgRx). The latter in my experience is what needs the most time.

    My recommendation: invest dedicated time into learning RxJS, for it is deeply entrenched into core Angular, and it is the basis of all more sophisticated state management libs. Don’t get overwhelmed, because in practice it will boil down to 6-10 operators you’ll use a lot (map, tap, filter, mergeMap, debouce, distincUntilChanged, take, combineLatest from the top of my mind) and the tail end of little operators you’ll look up when needed. https://rxmarbles.com is good for visual learners.




  • Assuming that your company has a profitable business, and you are working on the part brings in the revenue that pays the bills, you’ll keep that as long as your company is interested in keeping that business. Your CTO is burning money (and fast!), maybe they’ve picked that habit up in a zero-interest environment, but well interest rates aren’t zero anymore, so I’d be more worried if I were part of the secret internal startup.