Remove dependency on Parse JS SDK

New Feature / Enhancement Checklist

I am not disclosing a vulnerability.
I am not just asking a question.
I have searched through existing issues.

Current Limitation

Parse Server currently depends on the Parse JS SDK. This is because the Parse JS SDK is leading a double life - as a Parse client SDK and as a internal module of Parse Server that is uses for various features. This creates the following issues:

Difficult development; its adds a circular dependency where changes in the server requires changes in the SDK and vice versa.
Bloated client SDK; it contains code that is unnecessary outside of the Cloud Code environment.

Feature / Enhancement Description

Remove Parse Server's dependency on the Parse JS SDK. It should only be needed:

As a dependency alongside Parse Server if a developer wants to use the Cloud Code feature. In that case the developer needs to add the Parse JS SDK as a dependency themselves.
As a devDependency for the Parse Server tests of Cloud Code.

All elements of the Parse JS SDK that are currently in use in Parse Server should be moved to the Parse.Cloud namespace.

Future Enhancement

We could attempt a BYOSDK (Bring Your Own SDK) approach. If Parse Server allows to pass a SDK instance at start-up, then the developer is free to use any Parse JS SDK, as long as it's version compatible.

Roadmap

1. Merge feat: Add SDK Adapter #10256 as non-breaking change; parse-server will still have the JS SDK as prod dependency and use it in tests, but it should not rely on the JS SDK dependency directly anymore in prod code and instead use what's supplied via the SDK adapter (or fallback to JS SDK dependency as default if no JS SDK is supplied via parse-server config), e.g. error codes should be taken from the SDK supplied via adapter.
2. Migrate tests to use REST API directly and not go through JS SDK.
3. Migrate tests to use WS API directly and not go through JS SDK.
4. On next parse-server major release, move JS SDK from prod dependency to dev dependency if it’s still needed for tests; or remove completely if all test migrations are completed before that.

🚀 Thanks for opening this issue! We are excited about your ideas for improvement!

A possible approach could be to move the common internal APIs such as Parse.Error, Parse._encode, Parse._decode into a separate repository and use it as a dependency in Parse Server and possibly all client SDKs, if there's a way to do that. It may need to be abstracted in a way that makes it compatible across ecosystems. For Parse.Error that's easy with a JSON import, but Object transcoding may be a challenge.

@mtrezza

@mtrezza This might be easier than I thought, all we have to do is isolate which parts of the is Cloud Code, routers, hooks, triggers. Thats where the Object transcoding happens then just await import('parse/node') at the scope level.

I hope it is as easy as you make it sound - if you guessed, would you say this is an effort of days, weeks or months?

Depends on how fast you can move Parse.Error to another repo? This could take weeks

Here are all the features from the Parse JS SDK used internally on the Server. Most likely Parse.applicationId will give us the most trouble as it depends on the SDK maybe get it from config. I should probably note LiveQuery depends heavily on the Parse JS SDK.

module.exports = {
  applicationId: Parse.applicationId, // needs investigation
  AnonymousUtils: Parse.AnonymousUtils, // checking isLinked not needed as check for authdata does the same
  _decode: Parse._decode, // Cloud Only
  _encode: Parse._encode, // Cloud Only
  CLP: Parse.CLP, // Used for types not needed
  CoreManager: Parse.CoreManager, // Cloud Only
  Config: Parse.Config, // Cloud Only
  Error: Parse.Error, // Needs to be moved to another repo
  File: Parse.File, // Cloud only
  GeoPoint: Parse.GeoPoint, // toRadians can be moved to utils
  Polygon: Parse.Polygon, // containsPoint can be moved to utils
  Object: Parse.Object, // LiveQuery, Cloud, Auth
  Query: Parse.Query, // LiveQuery and Cloud
  Role: Parse.Role, // Used for className on Query creation can replace with `_Role`
  Schema: Parse.Schema, // Types and schema migration
  Session: Parse.Session, // Cloud Only
  User: Parse.User, // Authentication, Email verification, Cloud
  Server: ParseServer, // Cloud Only
};

From what I can tell developers should be able to run Parse Server standalone without the Parse JS SDK but for features like Email Verification, Authentication, LIveQuery, CloudCode and Schema Migration, DirectAccess (default true) would need the Parse JS SDK

What inside the JS SDK that makes these server features require it?

Parse.Error: can be moved into a separate repo in form of JSON file to import across client SDKs and server.
REST API calls: server should directly call its REST API without going through the SDK.

Then there are the tests that heavily use the JS SDK. Maybe none of the tests should actually use it but use the REST API. But given the amount of tests, it'd be an enormous effort to migrate them all.

test: Add REST test helpers and spec migration plan

Navigation Menu

Repository navigation

Remove dependency on Parse JS SDK #8787

New Feature / Enhancement Checklist

Current Limitation

Feature / Enhancement Description

Future Enhancement

Roadmap

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove dependency on Parse JS SDK #8787

Description

New Feature / Enhancement Checklist

Current Limitation

Feature / Enhancement Description

Future Enhancement

Roadmap

Activity

parse-github-assistant commented on Oct 23, 2023

mtrezza commented on Apr 15, 2025

dplewis commented on Apr 15, 2025

mtrezza commented on Apr 15, 2025

dplewis commented on Apr 15, 2025

dplewis commented on Apr 15, 2025

mtrezza commented on Apr 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions