Health to the Web

Security principles to live by never trust the frontend; seriously don't trust us! (because frontend can easily be bypassed or attacked) defense in depth; multiple not just 1 security check e.g. 2fa, csrf and same site, client and server checks   principle of least privilege, users lowest set of privileges by default OWASP Top 10 security risks for Web Applications  is a good guide to identifying what risks app builders should be securing again. Injection (including xss) is still in the top 3.  The  OWASP Cheat Sheet  is a good resource too for problems and solutions.  Lets look at some top ones: #1 Broken Access Control; exposure/modification/removal of information by unauthorized users. are access controls consistently applied everywhere needed? e.g. menus vs deep links to pages; apis not consistently enforcing auth checks what if bypass ui controls and hit apis directly? #2 Cryptographic failures ; crypto failures can lead to exposure of sensitive data ...

For me, Domain Driven Design and C4models are very complimentary. Domain Driven Design is about making the commitment to learn the business domain and the language of the business domain and then using models as the means to capture and grow the knowledge. C4models help breakdown the software system(s) and are quite technical: once you get past the Context diagram into Container and Class then it's even more technical. Btw I substitute sequence diagrams for class diagram for Level 4 of c4 and I only create Component diagrams when it's useful. Domain Driven Design uses Entity Relationship models and sequence flows which feed into and inform and also be informed by C4models. There's a nice symbiotic relationship there. I'm a big fan of the C4 Context diagram.  I always like to have "the system on 1 page" view for systems we build.  And at that high level, i t's understandable by all stakeholders including Product and Design and other teams involved.

React testing library has evolved and changed over the last couple of years and so has how we should use it. Here's a list of some of the latest best practices. The  Principles inform the philosophy of the library e.g. "write tests that closely resemble how your web pages are used" by the user. best practices follow the "which query to use guide" and prefer first to use get/queryByRole getByTestId() is now the least preferred (informed by Principals) import and use screen instead of de-structuring result of render @testing-library/user-event is preferred to fireEvent userEvent.type() fireEvent is not an accurate way for how a users does a click, user-events has all the events which get fired (informed by Principals) use eslint-plugin-testing-library because it will call out bad practices and recommends alternatives; helps to keep you up to date with latest recommend set everything to warning to start screen.debug()  can be useful to debug the dom screen.logTes...

Does you typescript code need to reference some global variables on window.* ?  e.g. const string = window.I18n.t() Are you getting typescript compiler errors when you do reference these? If so then the solution is probably a typescript global.d.ts file  for your app. You can add definitions for typescript Window in it like so interface Window { I18n : any ; some_global_key : string ; } Window is a built in typescript type that types window. When you define your own Window interface and add your custom properties to it, these will be merged with typescripts built in Window interface (thanks to typescript declaration merging ). I put the global.d.ts file in the root of my app. Typescript automatically picks it up and errors disappeared. Being explicit at a global level about all your globals is a better solution than scattering (window as any).I18n.t() all over the code (imo). references good article about various options for globals in typescript land interesting arti...

  interesting learning when using fetch and receiving a redirect response the browser will automatically follow a 301, 302 redirect from a fetch ajax call by default to the Location in the response header you can change the fetch redirect property to redirect:'manual' (so you can handle manually) but fetch does not provide a value in response status even tho the http response is 302 (why not?) redirect:'error' just throws error and there’s no way to check the response status code to know if it's a redicrect or some other kind of error I think this is a gap in fetch, if handling manually (redirect:'manual') then the status code should be available to check