SOC2 is just "the process we say we have, is what we do in practice". The process can be almost anything. Some auditors will push on stuff as "required", but they're often wrong.
But all it means in the end is you can read up on how a company works and have some level of trust that they're not lying (too much).
It makes absolutely zero guarantees about security practices, unless the documented process make these guarantees.
> What’s the point in degrading the UX without telling the user 1) why the UX is degraded, 2) what they can do about it? I
Because 1) everyone in the Apple world knows, and 2) they want the answer to "What can be done about it" to be "Shame your peers into switching to an iPhone".
And it works. A little too well, especially with younger folks.
The big issue I see when people have trouble with TDD is really a cultural one and one around the definition of tests, especially unit tests.
If you're thinking of unit tests as the thing that catches bugs before going to production and proves your code is correct, and want to write a suite of tests before writing code, that is far beyond the capabilities of most software engineers in most orgs, including my own. Some folks can do it, good for them.
But if you think of unit tests as a way to make sure individual little bits of your code work as you're writing them (that is, you're testing "the screws" and "the legs" of the tables, not the whole table), then it's quite simple and really does save time, and you certainly do not need full specs or even know what you're doing.
Write 2-3 simple tests, write a function, write a few more tests, write another function, realize the first function was wrong, replace the tests, write the next function.
You need to test your code anyway and type systems only catch so much, so even if you're the most agile place ever and have no idea how the code will work, that approach will work fine.
If you do it right, the tests are trivial to write and are very short and disposable (so you don't feel bad when you have to delete them in the next refactor).
Do you have a useful test suite to do regression testing at the end? Absolutely not! In the analogy, if you have tests for a screw attaching the leg of a table, and you change the type of legs and the screws to hook them up, of course the tests won't work anymore. What you have is a set of disposable but useful specs for every piece of the code though.
You'll still need to write tests to handle regressions and integration, but that's okay.
Webdev isn't complicated. Its actually pretty simple. Because its simple, you can use the extra time you saved to solve complicated problems. Which then brings it back up. When the platform makes THOSE problems simple, you just move on to solve other more complicated problems.
Basically, developers can support complexity <x>. No matter what you do to simplify it, you'll always push toward <x>, just getting more value out in the process. If you don't, your competitors will.
Also, even the most complex rollup/webpack/react/redux/styled-component/npm/blah/blah/blah setup has nothing on the kubernetes/kafka/databases/queues/whatever infrastructures of the world.
It just turns out that while your little pet project that cuts every corners to get something working has little on software development that requires everything to line up, be fast, reliable, comply with all the laws and regulations, and scale once your company grows and you suddenly have hundreds or thousands of people that need to work on the same stuff.
One thing to add: some people actually like setting stuff and optimizing infrastructure, build processes, setup, and pushing it to its limits. So development stacks quickly get optimized for a very common way to staff organizations: have a team that handles all the setup and infra, and a bunch of teams that build on top. So when you try to have 1 person or 1 team do everything, it feels like too much.
> this really seems like a case of prioritizing your organizational chart over the end user experience
No. It's case of being able to give the user more things they want, with each individual ones being built faster and optimized for their specific tasks without having to worry about the others. This comes at the cost of optimization of the whole (local maxima vs global maxima.).
If your product is something like, let say, Slack (one specific app that does one thing with a lot of features), it's a horrible fit.
If your product is something more like G Suite (several completely distinct apps that are semi related under an umbrella), that is where it shines. Other situations are things like internal apps where being able to DO something (at low cost) is often the priority.
There's a lot of ways to mitigate the UX impact, but yes, it has a UX impact. Its a tradeoff. Let's not forget that if you free your org of some burdens, they end up with more time to solve other problems, so it's not completely at the expense of the user.
> Is there any benefit to duplicating the implementation of business logic for each micro frontend
Im not too sure what else I can say that hasn't already been said. No coupling between the frontends means the complexity of the overall system doesn't go up with the amount of them you have and your organization can scale to infinity without increasing coordination. The architecture is best suited when you have a lot of distinct things (so duplication exists, but is kept to a minimum). You can still share stuff to avoid duplication in key parts. Injecting scripts, iframes, deep linking. Those are the frontend equivalents to backend microservices "service boundaries".
Imagine you have a React/Redux app with Rest endpoints. You have a dumb "Button" component. You share that with all the other apps. The Button is in React.
You now tie your entire ecosystem to React. Not having individual apps have to agree on dependencies is one of the benefits of micro apps, and you lost that. However, you only lost that for React, which many people agree is pretty darn good and not going anywhere. That's a tradeoff we take. Pure React components are also well encapsulated, so whatever the opinions are behind the Button doesn't pollute the apps. App owners are still free to architect their apps however they want: their only hard requirement is React.
Now, imagine you have a Medium style text editor built with React, Redux, and rest endpoints, complete with automatic draft save, a working publish button, onboarding experience, etc. If you share that, now all your apps have to agree on: backend, authentication, I18n, Redux, state management architecture, it probably uses local storage and cookies, is opinionated on what you do when logged out, and so on and so forth.
If you bring that editor in an app, you're now tied to all of this. If 100 apps use that editor, and they want to upgrade Redux in the editor, they all have to upgrade to get back to the same version. If you change the backend, you have to also upgrade all apps or keep the old endpoint forever. If you want to add an I18n language, you will have to rebuild/redeploy everything. If you don't encapsulate your state, its architecture will pollute the app, but if you do you're likely going to have a much more bloated library (more bytes, slower download). Apps are no longer free to make their own decisions.
It gets worse if you have transitive dependencies. Your app depends on A that depends on B that depends on C. Your app also depends on C. C releases a new version that your app wants. You now need to either bundle two versions of C, or upgrade the world. If C has global side effects, bundling 2 versions of C might not even be possible at all.
These kind of "full stack components" are tech debt the moment they hit your apps.
As the other reply to your post stated: you end up with the worse of both worlds. All the costs of micro-apps, with all the costs of a coupled monolith TOO. Its much worse than if you had picked either one or the other.
Version management is a fallacy as far as benefits of mono vs poly repos. You can do one way or another either way. You can have 1 version of everything in poly repos or you can have mixed versions in monorepos.
We follow an eventually consistent model. That is, we strive to have 1 version of dependencies for everything, but allow temporary deviation. Sometimes those deviations are less temporary, but usually for reasons that would have prevented upgrades altogether for everyone if we enforced a single version for everything.
The main benefits are around ownership (people can do whatever the hell they want to their repos) and tooling/scaling (whatever works for your tiny personal project will work for any of our apps without needing to scale them). Those are separate benefits from monolith app to micro apps (because again, you can do either with either model). You also have some minor benefits that would be easy to work around but are nice to get for free (eg: Github's default history is actually useful in the web UI)
The only tooling you need to manage poly repos is something to do pull requests at scale when something needs to happen everywhere. You can everything else (eg: build management scoped to individual projects) basically for free, you can always clone the entire repo without issues, etc etc etc.
> The article doesn't mention any details in that regard.
The whole point here is that you don't. You have dozens or hundreds of separate apps. They can use whatever framework they want. If you want to migrate framework, you just rewrite them from scratch, without any impact to another. It solves your current problem by making it a non-issue.
Consistency comes from the design system and style guide. If you have 2 frameworks, you have to start by having multiple implementation of the style guide. As long as the implementations are accurate, the look and feel of the apps will be the same even if they use different implementations. It has to be done well though.
As for Angular 1.x/React, the solution Ive used in the past in environment that didn't have micro apps was to build tools that let me React.render arbitrary react components inside of any Angular directive, and build a React component that let me render arbitrary angular directive anywhere, so I could migrate part of apps starting at any point without affecting the rest. I unfortunately don't have the code anymore, but it wasn't very hard to do.
> It doesn’t matter that they aren’t in the same repo, the minute one part of the app expects another to behave in a certain way there is a dependency regardless if that is expressed in code or not.
There's very little of this in this type of architecture. The dependencies are mostly "how do I deep link from one to the other" (which is generally kept to a minimum if you split the apps correctly), and a bit of "I called an api that stored data that another app will retrieve), but if you were planning on using something like a GraphQL schema on the BE, its not very different from having a public API used by a lot of integrators.
You still reduce build time, the amount of code someone has to wrap their head around to fully understand a given app, how dev tools scale, how deployment works, how long it takes to rewrite a section of the greater system from scratch, how easy it is to upgrade libraries, etc.
Unless you plan to have a 2-10+ apps to developer ratio, at least 50+ apps in the medium term, and looking into a future of 50-100+ devs at least, I wouldn't do this.
Exception: if your apps are very very distinct anyway. One company I worked at long ago where we did this, we were small, but the "screens" of our apps were very unrelated (no one really used more than 1-2 of them as part of their job), so it was very easy to split them up with zero impact on users.
I can't read the mind of the article's author, but usually in these types of articles about micro-whatever you want to stress how horizontal teams/libraries/ownership is to be avoided, because people "default" to having them, and you have to fight tooth and nail to make them understand it shouldn't be.
But for micro-FEs, there's a few things that, IMO, are unavoidable. A design system implementation (keeping its components as "dumb" as possible, no server api dependencies of any kind, no opinion about frameworks beyond the component technology it uses) is one of them. A few very very core things like authentication is another, as well as how all the routes glue together. There's a few more (nav, service workers, etc).
It should still be avoided unless absolutely impossible to avoid or if the benefits are overwhelming.
Having that kind of tight coupling (not only interfaces, but also libraries beyond the minimum you need for core things like the design system) partly defeats the purpose. If you have a lot of micro apps and they share dependencies/frameworks, you won't get the benefits of eventual consistency when the next big thing comes along.
For something like onboarding, any team handling that will either just be a "think tank" (PMs/Designers working with the actual owners of the individual affected apps to build the experience), or will be people who jump in other folks' code bases to implement it. Alternatively, they could only be responsible for building a suite of components that the app owners bring in their apps to glue things together.
No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group.
The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
But all it means in the end is you can read up on how a company works and have some level of trust that they're not lying (too much).
It makes absolutely zero guarantees about security practices, unless the documented process make these guarantees.