小程序开发双角色前端
Microservices are great — single-responsibility, domain-specific APIs that are independently iterable. A major web application can be composed of tens to hundreds to even thousands of these little guys.
微服务非常棒-可独立迭代的单一职责，特定于域的API。 一个主要的Web应用程序可以由数十到数百甚至数千个这些小家伙组成。
They can scale independently, give app teams the ability to code in the most appropriate language to get the job done, and leave you with a small blast radius if something fails (meaning the entire app stays up if a single microservice fails).
他们可以独立扩展，使应用程序团队能够使用最合适的语言进行编码以完成工作，并且如果出现故障(如果单个微服务出现故障，整个应用程序将处于启动状态)，则爆炸半径较小。
All the big guns are doing it too. Uber has ~2,200 microservices, Netflix has around 700, and Amazon… well, Amazon has a lot.
所有大手笔也都这样做。 Uber有约2,200个微服务，Netflix有约700个，亚马逊……还有很多。
But did you know you can apply the same basic principles to the front end? Micro doesn’t have to apply only to the back-end APIs.
但是您知道您可以将相同的基本原理应用于前端吗？ Micro不必仅适用于后端API。
Micro frontends follow the same concepts and offer the same benefits as microservices. They take your big UI monolith and slice it up into small, isolated, independently iterable chunks.
微前端遵循相同的概念，并提供与微服务相同的好处。 他们将您的大UI整体分割成小块，孤立的，可独立迭代的块。
Simple micro frontend architecture 简单的微前端架构After the initial build, chances are high that your UI is going to iterate more often than your back end. Be it big or small, you’ll go through more cycles, making the user experience the best you possibly can.
初始构建后，您的UI比后端进行迭代的机会更高。 无论大小，您都将经历更多的周期，使用户体验到最好的状态。
As you should!
如你所愿！
So doesn’t it make sense to divide your front end into bite-sized chunks? Yes!
那么将您的前端划分为一口大小的块是否有意义？ 是!
Now, I don’t want you thinking that building your application with micro frontends will make the user experience feel disjointed. That is not the goal. That’s an anti-goal. You want your app to continue to feel cohesive while quickly iterating on small features.
现在，我不希望您认为使用微前端构建应用程序会使用户体验脱节。 那不是目标。 那是反目标。 您希望您的应用在快速迭代小功能时继续保持凝聚力。
If you’re thinking about getting into continuous delivery, I would highly recommend considering also getting into micro frontends. Delivering small, incremental updates is exactly what this architecture is about, and with micro frontends, you’re enabling yourself to do so.
如果您打算进入持续交付，我强烈建议您也考虑进入微型前端。 交付小的增量更新正是该体系结构的目的，而借助微型前端，您将能够做到这一点。
If you decide to take the leap into micro frontends, congratulations! You’ve also opened yourself up to a pattern that will save you lots of headaches in the future: role-based applications.
如果您决定迈入微型前端，那么恭喜！ 您还打开了一种模式，该模式将为将来节省很多麻烦：基于角色的应用程序。
What is a role-based application, you ask?
您问什么是基于角色的应用程序？
A role-based application is a system composed of micro frontends and APIs with specific security restrictions.
基于角色的应用程序是一个由微前端和具有特定安全限制的API组成的系统。
Let’s take an example.
让我们举个例子。
You are the creator of a forum for celery enthusiasts, The Stalk Stalker. The architecture diagram for the forum looks like this:
您是芹菜爱好者论坛(The Stalk Stalker)的创建者。 论坛的架构图如下所示：
In your forum, you have users with different sets of defined permissions. Each set of defined permissions is known as a role. You have four roles in The Stalk Stalker:
在您的论坛中，您的用户具有不同的已定义权限集。 每组定义的权限称为角色。 您在The Stalk Stalker中扮演四个角色：
User — View and create posts. 用户-查看和创建帖子。 Moderator — View, edit, create, and delete posts. 主持人—查看，编辑，创建和删除帖子。 Admin — View, edit, create, and delete posts, and manage moderators. 管理员-查看，编辑，创建和删除帖子，以及管理主持人。 Banned — Nothing. 禁止-没事。Each person who signs into your app is associated with a role. In your three micro frontends, you have clear boundaries on who can do what. So you set a restriction on each of your services to limit the scope down to specific roles.
每个登录到您的应用程序的人都与一个角色相关联。 在您的三个微型前端中，您对谁可以做什么有明确的界限。 因此，您对每个服务都设置了限制，以将范围限制为特定角色。
Anyone with the appropriate role can access that part of the application. More importantly, anyone without the allowed role is explicitly denied access to the micro frontend.
具有适当角色的任何人都可以访问应用程序的该部分。 更重要的是，任何没有允许角色的人都被明确拒绝访问微前端。
If your API is public, which it totally should be, these permissions must also be enforced on the API.
如果您的API是公开的(应该完全公开)，则这些权限也必须在API上强制执行。
There are many different ways to add security to a web application and supporting APIs. With role-based apps, you must include the role somewhere in the auth. Be it a separate header or a behind-the-scenes lookup, you must validate that the user has permission to do what they are trying to do.
有很多不同的方法可以为Web应用程序和支持API增添安全性。 对于基于角色的应用程序，您必须在auth中的某个位置包含该角色。 无论是单独的标头还是幕后查找，您都必须验证用户是否有权执行他们要尝试执行的操作。
In your micro frontend, you need to validate that the user has the role tied to that app before any of the content renders. The app is small and focused, so it’s perfectly OK to hardcode the allowed role in the source code. The flow could be as simple as Login > Look up user role > User has role? > Unauthorized/OK.
在您的微型前端中，您需要在呈现任何内容之前验证用户是否具有与该应用程序绑定的角色。 该应用程序小巧，专注，因此可以在源代码中硬编码允许的角色。 该流程可能很简单，例如登录>查找用户角色>用户是否具有角色？ >未经授权/确定。
The API will do something similar, except it shouldn’t be tied to a login event. The user will already be logged in by the time any API calls are made. So be sure to have identifying information about the user in the authorization token. Something like OAuth 2.0 provides the context necessary to uniquely identify a user via a JWT (JSON Web Token).
该API会执行类似的操作，只是它不应与登录事件联系在一起。 在进行任何API调用时，用户将已经登录。 因此，请确保在授权令牌中包含有关用户的标识信息。 诸如OAuth 2.0之类的东西提供了通过JWT(JSON Web令牌)唯一标识用户所必需的上下文。
Adding a Role header to your API requests will allow you to easily add security tests to your application. Thorough, exhaustive security tests are a must when building an application today. Malicious users are out there who will try to exploit your system, and you need the confidence that you've set up your micro frontends and API properly.
在API请求中添加Role标头可以使您轻松地向应用程序添加安全测试。 当今构建应用程序时，必须进行彻底的详尽安全测试。 恶意用户会尝试利用您的系统，因此您需要确信已正确设置了微前端和API。
I have provided a Postman collection and environment in my GitHub repo that will automatically test your API for security holes. Use this to help make sure you have the proper micro frontend and API design to support your app.
我在GitHub存储库中提供了一个Postman集合和环境，它将自动测试您的API的安全漏洞。 使用此功能可确保您具有正确的微前端和API设计以支持您的应用。
There really isn’t a right or a wrong way to provide access to your micro frontend. I take that back. There are definitely wrong ways.
提供对微型前端的访问确实没有正确或错误的方法。 我收回之前说过的话。 肯定有错误的方法。
The two most common ways to give your users access to micro frontends are through subdomains and routes.
使您的用户访问微前端的两种最常见的方法是通过子域和路由。
You see both patterns all over the internet, and it is entirely up to you how you want to implement.
您可以在Internet上看到两种模式，而这完全取决于您要如何实现。
If you are big into setting up DNS routing tables, subdomains might be your new best friend. If you avoid DNS routing like the plague, routes will be the way to go. Either approach you choose, providing your users with a seamless experience is your main objective.
如果您热衷于设置DNS路由表，则子域可能是您最好的朋友。 如果您避免像瘟疫这样的DNS路由，那么路由将是正确的选择。 您选择的任一种方法都是为您的用户提供无缝的体验。
You are already building microservices for your API. It doesn’t make sense to continue building your monolithic front end.
您已经在为API构建微服务。 继续构建您的整体前端没有任何意义。
Break it up, iterate independently, and push small, incremental changes. You don’t want to redeploy the entire front end because you misspelled a label, right?
分解它，独立进行迭代，并推动小的增量更改。 您不想因为标签拼写错误而重新部署整个前端，对吗？
Build security directly into your apps. Define roles with a known set of permissions. Lock it down.
直接在您的应用程序中构建安全性。 用一组已知的权限定义角色。 锁定它。
Your goal as a software developer, manager, product owner, QA analyst, business analyst, tech writer, etc. is to make the best software for your customer. Provide the best experience by mitigating downtime and improving security.
您作为软件开发人员，经理，产品所有者，质量检查分析师，业务分析师，技术撰稿人等的目标是为您的客户制作最好的软件。 通过减少停机时间并提高安全性来提供最佳体验。
The software industry is moving at breakneck speed, and it isn’t going to slow down any time soon. Expectations regarding agility, user experience, and security are at an all-time high, and you can keep up if you simply break it down.
软件行业正以惊人的速度发展，并且不会很快放缓。 对敏捷性，用户体验和安全性的期望空前高涨，只要将其分解，您就可以继续前进。
翻译自: https://medium.com/better-programming/micro-frontends-role-based-applications-and-you-5d6cd8d796eb
小程序开发双角色前端
