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 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.