经典案例｜使用Supabase解决可视化大屏项目的常见问题

敏博科技专业致力于应急管理行业，提供以物联网技术和感知预警算法模型为核心的先进产品和解决方案。应急管理行业的业务非常繁多和复杂，很多时候都需要在短时间内交付出稳定高效的业务系统。如下两张图某市的安全生产监测预警系统
在这里插入图片描述

MemFire Cloud应用开发服务，采用开源的Supabase，兼容国内开发生态，内置通用服务，简单易学，加速小程序/移动应用/WEB网站的开发，降低开发/运维成本。

Supabase在简化开发过程，提供开发人员所需的核心后端服务，使开发人员能够更轻松地构建和管理应用程序的后端部分，同时让前端人员自己了解业务与数据库表结构设计前端数据渲染与交互通讯减少沟通成本，从而加速应用程序的开发周期。

MemFire Cloud引用了supabase的整套工程并且接入到自己的平台里，保证数据不在国外的问题了，方便追溯。而且在国外的话访问速率也是一个问题，有的网络情况可能访问不到supabase的服务，这也是为什么我没有选择直接使用supabase的重要原因之一。国内的项目当然更适合国内自己的生态啦！

那么下面我将分享使用MemFire Cloud开发这两个应用的部分案例和所遇到的问题。

使用MemFire Cloud开发可视化项目遇到的一些问题

身份认证服务

登录方式

MemFire Cloud提供了极其便利和丰富的身份认证服务。你可以通过几种方式来验证你的用户：

微信小程序
电子邮件和密码
Magic links（一键登录）
其他社交媒体登录认证服务商
手机号登录

但是往往用户信息功能通常都是在自己的服务器里存储，这样有利于更多的可定制化一些其他的功能，所以我们需要将自己的用户表和MemFire Cloud的用户表进行关联。

关联用户

你可以在 表编辑器 的 Schema auth 里面找到 users 表，这个表就是MemFire Cloud身份认证所需的用户信息。

那么问题来了，我们自己的业务系统里的用户只能通过账号和密码进行登录，但是MemFire Cloud的身份认证服务没有账号的方法，所以我们将使用邮箱账号的方式进行注册和登录，只需要在自己的业务系统里注册和登录的时候后面添加一个邮箱后缀即可。

下面是邮箱注册的方法

//    邮箱注册
let { data, error } = await supabase.auth.signUp({
  email: 'black@nimblex.com',
  password: 'xxxxxxxx'
})

下面是邮箱登录的方法

 //    邮箱登录
 let { data, error } = await supabase.auth.signInWithPassword({
  email: 'black@nimblex.com',
  password: 'xxxxxxxx'
})

这样就完成了身份认证的功能

权限（RLS）

应用场景

假如所有的用户只能获取该用户所属部门的数据，不能获取非本部门的数据。

以上场景可能大部分人第一想法是将这个数据通过部门的ID进行关联查询，但是这种做法会导致重复的代码查询逻辑和更多的代码维护量，所以选择使用RLS是最佳选择。

什么是RLS

全称：Row level security，行级安全，允许系统管理员为数据库表创建访问策略（policy），以约束数据的可见性。当为一个表创建了policy后，相当于为该表增加了一个高优先级的过滤器。当用户访问该表时，如果policy生效，则会根据policy中定义的过滤条件来决定用户可操作的数据集合。

开启RLS

界面上可以比较方便的对每个表开启和关闭RLS，但是不方便代码维护，因此这里采用SQL语句的方式对需要开启RLS的表进行管理。基本的语法

alter table xxx enable row level security;

权限模型

目前项目中的数据权限统一采用一种模型：用户可以查看本部门以及子部门的所有数据。因此RLS规则相对简单。

插件依赖

为了提高RLS的性能，这里引入一个Postgres插件supabase-custom-claims，该插件可以将一些用户属性信息写入到auth.users表中，并且在用户登录时写入到会话上下文的变量中，方便直接使用。这里我们通过该插件将用户的部门id以及部门行政区域编码写入到用户session缓存中。

用户同步

为了确保用户不论通过supabase还是通过后台管理系统里的注册、添加、修改密码、修改部门等功能，两边都保持数据同步，需要为此创建触发器，进行用户的同步。这里需要通过set_claims修改用户的属性信息，将dept_id和code写入auth.users表。代码参见。

初始用户搬迁

将已经存在的用户从sys_user表同步到supabase，代码参见。

RLS规则

为了满足权限模型的需求，RLS规则基本上会经常使用到如下两个判断

可以看当前部门的数据

-- 假设表中有dept_id字段，则RLS规则写法如下
get_my_claim('dept_id') = to_jsonb(dept_id::text)
-- 如果表中只有行政区域编码，则RLS规则写法如下 (可能有的表不叫qxbm，比如xzqhdm，请根据实际情况修改）
get_my_claim('dept_code') = to_jsonb(qxbm::text)

可以查看子部门的数据

-- 假设表中dept_id字段，则RLS规则写法如下
dept_id in (select dept_id from sys_dept d 
    where get_my_claim('dept_id'::text) #>> '{}' = any (string_to_array(ancestors, ',')) 
)
-- 表中只有行政区划编码的情况
qxbm in (select code from sys_dept d 
    where get_my_claim('dept_id'::text) #>> '{}' = any (string_to_array(ancestors, ',')) 
)

视图处理

视图可以简化开发，但是存在一个需要解决的问题，Postgres不支持为视图创建RLS，并且默认情况下视图对应的表如果配置了RLS规则，查询视图时规则是不生效的，导致查询视图会把不应该看到的数据也返回了。要解决该问题，必须为视图开启security invoker。

PostgreSQL 15之前的版本如何在 PostgreSQL 中的视图添加行级安全
PostgreSQL 15 PostgreSQL中的视图权限和行级安全性

基本用法：

-- 创建视图的时候开启
create view new_type_view with (security_invoker = true ) as select * from source_data;

-- 对已有视图开启
ALTER VIEW xxxx SET (security_invoker = on);

RLS规则

从项目角度，不需要为所有表创建RLS，通常只需要为主表创建RLS。主表的意思是约束数据查询范围的表，比如部门表、企业表等。

另外一个判断是否需要创建RLS的依据：是否有业务场景根据用户输入直接查询该表。

比如：只要约束了部门表，用户就无法从sys_dept表中查询不属于自己权限范围内的部门ID，也就无法通过部门ID去查询更多数据。

sys_dept 表

alter table dept enable row level security;

-- 允许用户查询所在部门的信息
CREATE POLICY "可以查询当前部门信息" ON "public"."sys_dept" 
AS PERMISSIVE FOR SELECT TO public
USING (get_my_claim('dept_id') = to_jsonb(dept_id::text))

-- 允许用户查询子部门的信息
CREATE POLICY "可以查下子部门信息" ON "public"."sys_dept" 
AS PERMISSIVE FOR SELECT TO public
USING ( get_my_claim('dept_id'::text) #>> '{}' = any (string_to_array(ancestors, ',')) )

sys_enterprise 表

alter table sys_enterprise enable row level security;

-- 允许用户查询所在部门的行政区划的数据
CREATE POLICY "可以查看当前行政区划的数据" ON "public"."sys_enterprise"
AS PERMISSIVE FOR SELECT TO public
USING (get_my_claim('dept_code') = to_jsonb(xzqhdm::text))

-- 允许用户查询子部门的行政区划的数据
CREATE POLICY "可以查看下级行政区划的数据" ON "public"."sys_enterprise"
AS PERMISSIVE FOR SELECT TO public
USING (xzqhdm in (select code from sys_dept d where get_my_claim('dept_id'::text) #>> '{}' = any (string_to_array(ancestors, ',')) ))

删除Policy

删除很简单，可以通过界面删除，也可以使用SQL删除

drop policy xxx on xxx;

多种类多维度的数据统计

在数据可视化大屏当中难免会遇到一个情况：需要统计多种类、多维度的数据来填充单个卡片，例如下图
在这里插入图片描述

在后端开发人员的设计接口开发思路里，这段SQL语句肯定要用到Group By语法，并将这几种类型的统计汇总后统一返回给前端。

但是在Supabase的API里计数查询不支持类似于Group By方式查询，只能针对单个条件进行计数，代码如下：

const { count, error } = await supabase
  .from('countries')
  .select('*', { count: 'exact', head: true })

那么在前端是否就只能根据上面卡片的需求，调用8次api呢？

当然不是！因为这样会造成重复的过多代码量和线程阻塞，后期维护复杂！

如何解决

所以针对这样的问题我总结了以下几种方法：

使用数据库函数，让后端人员开发数据库函数，前端使用SupabaseApi调用 const { data,error } = await supabase.rpc('func_get_risk_conut') 函数获取统计数据。
可以考虑使用查出表内所有数据，在前端进行计算。如果涉及多表可以建立视图表。（该方案仅适用于只涉及到单表，且数据量不大的场景）
让后端人员针对该业务（比如不同维度和种类的风险）功能进行建立视图，然后前端调用视图查询。

小结

通过实践发现方案2和方案3均有不同程度的性能问题，因此方案1更佳。

总结

MemFire Cloud 功能强大，使用它开发项目的效率极高，项目开发的周期能够被缩短，同时还能减少投入的后端开发人员，并且换了一种开发模式。可能正常的开发模式是，后端设计流程和开发接口，前端开发页面和对接接口，但现在只需要前端开发页面、设计流程和获取数据即可。

再谈谈优缺点：

MemFire Cloud 支持多种常见的身份认证方式，包括email、各平台登录，为开发者提供了灵活的选择，适应不同用户的偏好。但是存在着一些 局限性 ，尽管提供了多种认证方式，但再一些特殊需求下，开发者可能需要更多的自定义选项，这方面的灵活性可能不如一些专业身份认证服务。
RLS允许开发者以行级为单位和控制用户对数据库中数据的访问权限，实现了精细的访问控制和数据保密性，并且RLS是再数据库层面实现的，这意味着访问控制直接集成到数据库引擎中，提供了高效和可靠的数据保护。但是对于复杂的数据结构和多层级的访问控制，配置可能会变得复杂，需要谨慎的规划和设计，以确保正确的分配权限。
Supabase的API在提供便捷的同时，开箱即用无需复杂的配置就可以开始使用，创建表后可以直接通过前端调用api的形式进行数据库的增删改查。但还是很难满足比较苛刻和复杂的查询需求。

通过这个项目了解到MemFire Cloud和学习了Supabase的功能，其中它的一些特性比如Postgres数据库服务、认证服务、自动生成API、文件存储等功能是这次项目的主要内容，还有更多的功能与服务例如REST ApiRealtime、静态托管、云函数等功能。

考虑到Supabase是一个不断发展的开源项目，未来也会不断增强其现有的功能和开辟新的功能，例如数据库查询优化、安全性增强、第三方集成、更多的数据库语法API，我相信 **MemFire Cloud**在未来会发展成一个更加成熟，应用业务面更广，使用性更强的工具。