Roadmap for SDK v2.0 (Modernize SDK)

[ErnoW]

Roadmap for SDK v2.0 (Modernize SDK)

The core purpose of v2.0 of the SDK will be to modernize the current tech setup. Currently, it has been built by using a fork of the Parse SDK. In order to modernize the setup, we will be moving away from this fork and setup our own architecture. Below is a list of key features that we plan to implement:

• Use modular setup by implementing a mono-repo and sub-packages for optional functionalities. This way a developer can use certain functionalities without having to deal with dependencies of other sub packages. An umbrella package will also be exposed that includes all subpackages.
• Use rollup or webpack as bundling tool to allow for tree-shaking
• Natively written in Typescript for more security about correct Typings
• Better written tests and code-coverage
• Better cross-chain compatibilities, and connections to chains (connect to multiple networks, eager connections to chains if possible)

Of course, the current functionality of the SDK remain the same or will be improved, including

• builds for browser, react-native and nodejs
• Interaction with the moralis-server, chains/web3, webAPI/solanaApi

---

Please, leave suggestions and requests in the comments

[comingAlive]

Make SDK and its architecture friendly for contributions and future-proof:

• ES Modules first
• Serverless, maybe even Edge functions first (https://nextjs.org/docs/api-reference/edge-runtime#unsupported-apis)
• SvelteKit support
• React 18 Server Components support
• First-class support for Zero-bundle-size setups (dynamic imports with Svelte preload functions or RSC)

[weeliem]

Is the version 2 fixed these warning? screenshot

[ErnoW]

Is the version 2 fixed these warning? screenshot

Yes, these warnings will be eliminated in v2. As we are releasing the support of magiclink, walletconnect etc. as separate packages.

[kantorcodes]

Hello,

Wanted to check in around this. Do we have a target release date for v2?

[bard]

Please, leave suggestions and requests in the comments

If the API needs to be accessed through a stateful object (e.g. because of a persistent connection for push events), provide a constructor or factory so that the state stays self-contained.

Moralis.start seems to rely heavily on global state, which makes 1) mocking in tests hard and 2) some types of bugs possible.

Regarding 2), consider:

const moralisClient = createMoralisClient(config)
// ... many lines later or in another file ...
const result = await moralisClient.Web3API.account.getNFTs(params)

vs.

Moralis.start(config)
// ... many lines later or in another file ...
const result = await Moralis.Web3API.account.getNFTs(params)

In the first example, forgetting the first line would cause a compile error. In the second, the error would go undetected through build, deployment, and startup, and at some point cause a runtime error.

[ivan-liljeqvist]

@bard great feedback!

Also for everyones knowledge we have early alpha versions available to try already (very early)

https://www.npmjs.com/package/moralis/v/2.0.0-alpha.1

https://github.com/MoralisWeb3/Moralis-JS-SDK/releases/tag/moralis%402.0.0-alpha.1

[saike]

Please, enable option to not rely on axios in Node SDK. And add possibility to use fetch instead. For example Supabase Edge Functions throws XMLHTTPRequest is undefined error. Thx!

[ErnoW]

Good point, we aded it on the roadmap to configure the Requestcontroller manually, to remove the need of axios

[ErnoW]

Closing this issue, as v2 has been released for a while now. For bugs: create a new issue here at Github For questions: reach out to us in discord and forums, we have active support in these channels