能否仅使用DirectusSDK替代REST/GraphQL？用其替代GraphQL请求有何弊端？

问题1：是否可以仅使用Directus SDK完成全量接口调用，无需手动对接原生REST或GraphQL接口？ #

完全可以实现。

• 官方维护的JavaScript SDK本质是对Directus全部原生REST、GraphQL接口能力的全链路封装，覆盖了从用户登录鉴权、Token自动刷新、业务数据CRUD、文件上传下载、实时数据订阅、关联字段查询、权限校验到自定义扩展端点调用的所有核心功能。
• 开发过程中不需要手写任何原生fetch/axios请求逻辑，也不需要自行拼装GraphQL查询语句，通过SDK暴露的标准化方法即可完成全业务流程的请求发起。哪怕是自定义的非内置接口，也可以通过SDK提供的通用请求方法完成调用，无需单独做接口适配。

问题2：相较于直接手写发起GraphQL请求，使用Directus SDK开发存在哪些潜在弊端？ #

这类弊端不是SDK本身的设计缺陷，而是封装特性带来的场景适配差异，主要包括：

• 包体积开销更高：SDK内置了全场景的请求处理逻辑，就算通过Tree-Shaking裁剪，全量引入的体积也会远大于手写几行轻量GraphQL请求的代码量，对极致追求轻量的前端项目不友好。
• 定制灵活度存在边界：SDK对请求格式、拦截逻辑做了固定封装，若需要实现非常细粒度的请求定制（比如特殊的请求重试规则、非常规的鉴权头处理、复杂的动态查询拼装），往往需要绕开SDK的默认封装逻辑，额外增加适配成本，灵活度不如直接手写GraphQL请求。
• 版本绑定的隐性成本更高：SDK和Directus服务端为强版本依赖关系，若服务端做了大版本升级，SDK需要匹配对应版本才能正常调用，否则容易出现接口不兼容报错；而直接手写GraphQL请求的场景下，只要服务端GraphQL Schema没有发生破坏性变更，基本不需要跟着版本同步修改代码。
• 调试链路更长：手写GraphQL请求时，可以直接把完整查询语句粘贴到Directus内置的GraphQL调试工具中验证，出问题可以直接定位原始请求参数；走SDK调用时，原始请求会被封装层做转换，需要手动开启SDK的调试日志才能拿到完整请求报文，排查问题的链路更长。

内容的提问来源于stack exchange，提问作者Cem Kaan