前面的背景部分，纯是记录一下，不用看。

背景介绍

这是一个探索性质的工作。

当时公司基于众多研发团队的情况，希望能找出一条减少研发工作量的路线，除了GraphQL，还有其他的路线，比如自研低代码平台，采用国内的一些后台开发平台，代码生成器，还有一些简化接口开发的工具等等。

因为现实的情况，一些预研工作没有落地，而GraphQL，实现了部分落地。GraphQL可以实现增删改（@MutationMapping）、查（@QueryMapping）、订阅推送（@SubscriptionMapping）。

但是在工作实践中，我们认为（仅基于公司当前的情况），增删改这些操作还是使用普通的Rest Api比较好，订阅推送用WebSocket+STOMP比较好（WebSocket SpringBoot STOMP的实现），查询方面，后台系统的列表查询相对复杂，没有用GraphQL。

主要将GraphQL应用在聚合信息接口上，我们的项目角色众多，一套数据不同角色需要展示的不一样。以前的做法：

1、搞一个大接口，返回所有的东西，不同的客户端自己选择需要的数据进行展示。优点是服务端没什么开发量，缺点是一抓包，数据就泄露了。

2、不同的端搞不同的接口，同一个订单数据，买家一个接口，卖家一个接口，运营平台一个接口，优缺点与上一种反过来。

3、前端调用多个接口，进行拼装。优点是前端有一定的数据选择权，缺点是接口多，且一个页面要发送多个HTTP请求，资源消耗相对多。

这三种做法我们之前都实践过，第二种方案，一旦管理不好，代码就乱得很，不同的用户端，随着项目的演进，需求变更频繁，两三个迭代下来，本来很清晰的业务逻辑，最后代码写得五花八门。第一种倒是省时省力，就是数据安全性属实有点不靠谱。第三种嘛，遇上好说话的前端开发同学还好......反正我们之前就遇到过因为微服务开发人员不愿意提供聚合接口，而导致前后端吵起来了，一个办公楼层听得清清楚楚，最后矛盾上升到技术负责人那去了。

经过我们实践中的应用，GraphQL可以相对好地应对这种情况——不可能完全解决。

实现

?Java的GraphQL实现有很多第三方JAR，例如graphql-java-kickstart、Netflix DGS等，我们采用的就是Spring官方的「Spring for GraphQL」。

依赖：

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-graphql</artifactId>
</dependency>

配置：

spring.graphql.graphiql.enabled=true
spring.graphql.printer.enabled=true

表设计：

实践中，我们遇到了一些小问题。

Long的处理：

GraphQL定义的数据类型，没有Long，而我们在实践中，一般都是用Long做主键的，解决方案有两种：

• 使用graphql-java-extended-scalars，扩展了一些类型，就包含Long。
• 将Long转为String。这是我们使用的方案，原因也很简单，接口会提供给页面使用，而JS处理Long数据会损失精度，之前也是转为String使用。

日期时间的处理：

方案也同上。

• graphql-java-extended-scalars有日期时间类型的扩展，只是对应的Java类不是Date，而是「java.time.OffsetDateTime、java.time.LocalDate、java.time.OffsetTime、java.time.LocalTime」，格式是：2024-04-17T07:01:58.000+08:00，要想变成常用的“2024-04-17 07:01:58”还需要转一下。
• 直接转为Unix时间戳，类型为String。这个也很常用，我印象中JS在处理“2024-11-11”这种数据的时候，有时候会当成减法来操作，所以后来服务端就统一返回时间戳了。

schema.graphql：

scalar DateTime
@specifiedBy(url: "https://scalars.graphql.org/andimarek/date-time.html")

type Query {
    userById(id: ID): UserVo
    findUser(userQueryParam: UserQueryParam): ResultUser
}

type UserVo {
    id: ID
    userName: String!
    createTime: DateTime
    account: AccountVo
    idCard: idCardVo
    idCardPics: [idCardPicVo]
}

type AccountVo {
    id: ID
    mobile: String
    pwd: String
    userId: String
}

type idCardVo {
    id: ID
    userId: String
    idCardNo: String
}

type idCardPicVo {
    id: ID
    userId: String
    picUrl: String
}

input UserQueryParam {
    mobile: String
    idCardNo: String
}

type ResultUser{
    code: Int!
    msg: String!
    data: UserVo
}

说明：

• !代表此字段是非空的，服务一定会返回给你一个值。ResultUser设置的data，没有!，代表此值可以为null。
• []代表数组。
• input代表设置了一个输入的参数类。
• type Query代表设置的查询方法。还有变更、订阅类型，本例不再赘述。
• 一般我们返回给前端的数据体，都带有code、msg、data，所以通常用ResultUser这种格式。

Controller：

@Controller
@Slf4j
public class UserQueryController {
    @Autowired
    private UserService userService;

    @QueryMapping
    public UserVo userById(@Argument String id) {
        UserEntity userEntity = userService.getUserById(Long.valueOf(id));
        log.info("DB信息：{}",userEntity.toString());
        return this.buildUserVo(userEntity);
    }

    @QueryMapping
    public Result<UserVo> findUser(@Argument UserQueryParam userQueryParam){
        log.info("查询参数：{}",userQueryParam.toString());
        UserEntity userEntity = userService.findUser(userQueryParam.getMobile(),userQueryParam.getIdCardNo());
        return  Result.success(this.buildUserVo(userEntity));
        //return Result.fail("无此数据");
    }

}

启动服务后，可以访问http://localhost:8080/graphiql?path=/graphql

或者使用PostMan进行调试。