I am playing architect for the first time at work setting up an Angular 7 frontend to talk into what is technically a second application, a .NET Core 2.1 ReST API. This is not me working on an Agile team. This is me cowboy coding with limited oversight. I once botched an interview elsewhere wherein the team wanted someone who could set an app up from end-to-end and I had to qualify that as a worker bee on an Agile team there were really some things that I never touched like the logging implementation or whatever apparatus might be for managing user logins. Well, now it seems I have passed a similar interview instead of failing it and I am in a position where I need to shine. The logging part is easy, but the managing of user logins has led me to make some compromises. A coworker suggested that it was wise to have as much of the Angular app as possible behind the lazy-loading of secondary modules. This, he felt, would allow the application's version of Angular to be easier to upgrade. This seemed smart and I envisioned a scenario in which users would land at a static, bland home page which just had some copy on it and then when navigating the menu system hit a secondary module and lazy-load all of the services. One wrinkle in the works was the manner in which adal.js works. It redirects you to another server and back to your app and when you come back a bunch of gunk chases a pound sign in the URL making it impossible for the URL to be a nested URL in a useHash strategy. You have to come back to the root of the site and thus adal.js is at least one service that must be uploaded upfront and not walled off behind a secondary lazy-loaded module. Ouch! At the C# API side, I have an Onion Architecture approach going on and I wanted to hand the tokens from adal.js that I got from the Angular app mundanely through the UI down to the Infrastructure project where I could have code to interact with Active Directory, yes, walled off. Again, this too is impossible... or at least very hard. All of the examples online for catching the token that I could find wire the token assessment directly into the middleware of Startup.cs in the UI. From there one fishes out who the user is in the controllers in the UI. Yuck! At first this was appalling for me, but then I begrudgingly found acceptance when I realized that the Inversion of Control bootstrapping for my Onion Architecture was happening in Startup.cs anyways and I could thus kinda squint my eyes and tell myself that this was just more of the bootstrapping. Of course the problem with that lie is that the bootstrapping herein is doing more than it really should do. It should not be that fancy-schmancy. It should be stupid, devoid of logic. I've had to make some compromises, eh? While I am speaking of impossible architecture, I want to mention that I'm not a big fan of patterns as there is often little to think about. Maybe you need to know the façade and factory (repository) patterns, but that is it. The others are either esoteric fringe case contortions or of overarching architecture at a level where you won't have to make a decision. The strategy pattern seems legit on the surface and then never comes up. I once botched a different interview (phone screen) in which the company had ten different technologies (at least) going on and when they started a project they just picked the best language for the job. Good luck recruiting candidates guys and good luck doing maintenance. Most places are just on a particular stack and if everything in your environment is Java the next app is going to be Java too. The only thing to wonder about is if you are going to use the latest and greatest Java or the version you've been using. The photos here were taken on the eve of this most recent Christmas Eve in the Mall of America in Bloomington, Minnesota.
No comments:
Post a Comment