虽然说一般架构在公司里都是后端做的，一般架构师主要也是后端，前端不怎么做架构，但是面试官问你这个问题的时候，总不能这样回答吧
下面云哥来给你谈一下对前端架构的理解，比较口语化的表达：前端架构主要包含哪些方面
1 中间层：这里所谓的中间层，根据我当时讲的我主要说的就是利用nodejs或者其他服务。
1、做一个中间层服务层，将一些定期更新的数据由这个服务器，做数据缓存然后前端来调用这个接口，而不是直接调用后端的接口服务器。
2、接口组合和拆分中间层：也就是说你是要一把把数据全部给前端还是分开数据给前端，作为后端开发，他们接口也有很多事接口组合或者相互接口之间做依赖，那这个工作也交给前端来做。后端只需要做精细化的基础接口，然后由这个中间服务器做接口的组合和拆分。
3、这个中间层有的时候也会做一些类似服务器端渲染的或者seo信息的存储和变化，做一个定期的信息变更。
4、当然也有其他用途，这个可能每个公司都会有扩展吧，比如一些依赖库，或者静态资源等处理。
2 代码自动化发布：这个自动化发布，其实jenkins,但是有做做一些定制类测配置，比如js库的源配置，项目本身目录配置相互调用入口配置等。当然也包括静态服务器部署，代理配置，开发环境、测试环境、生产环境等多环境部署等，当然这里还包括一些特殊的东西，比如打包后再客户端注入版本，然后客户端检测版本更新提示等，当然也包括微服务，公共组件调用(类似卡片市场等)(实现方式比较多)一些配置等。
3 组件库(UI组件库，业务组件库)：UI组件库，这个不说了很好理解，单纯的就是服务于业务，本身不含有业务代码，但是参数和接口丰富，满足平时开发使用，当然也会有一些基于现有组件库二次升级的，自己维护。再就是业务组件库，这个业务组件利用git subtree 实现每个项目中子项目，根据业务需求封装一些比较复杂的或者公用需求的一些组件(像现在很多的内部低（少）代码，组件，都是基本上拿过来改一些配置项和参数，就可以使用)都有这个业务组件去完成。
4 微服务方案：其实这个微服务，不要单纯理解成为现在市场流程的乾坤等，而是要理解就是将服务拆分，可能由不同团队维护或者由不同项目组维护，可能技术栈不同，但是都能集成。
我遇到三种情况：
1、就是乾坤，但是不能满足所有业务需求。它其实就是一个在一个基座应用中加载了其他子项目，内部能够实现隔离而已，但是如果我是需要在一个子项目中，又要在局部再起嵌入一个子项目或者服务的话，就不适用了。
2 、卡片应用，更加方便。也就说我们将每一个小的服务都拆成卡片服务（够微）然后打包成commonjs(将css和静态资源也打包进来),然后动态加载这个commonjs，然后实现嵌入到你的页面中。这个够帅。
3 、就是利用cookie，实现将基础信息通过cookie,实现其他子应用的基础信息共享和分发，这个技术比较老了，但是还有很多公司再用。这块必须要注意子应用必须要有这种页面跳回基座的能力或者拦截基座分发信息失效的能力。这样才能实现信息的共享和同步，这个比较适合大项目拆分。严格讲也不是微服务。