Parse SDK Flutter: a Dart and Flutter client for a self-hosted Parse backend

Two packages in one repository, and the split is by platform

The repository publishes two packages, and the readme gives their names and their package types. parse_server_sdk is the Dart package, and it lives in the packages/dart directory of the repository. parse_server_sdk_flutter is the Flutter package, and it lives in packages/flutter. Both are on pub.dev, with the readme linking each to its package page. That split is the usual reason a Flutter SDK is not just a Dart SDK with widgets bolted on, and it is the first practical decision a consumer makes. A project that only needs to talk to a Parse Server from a command line tool or a server side Dart service can depend on the Dart package alone, while an application with a UI reaches for the Flutter one. The readme frames the whole repository in one sentence, that these libraries give you access to the powerful Parse Server backend from your Dart or Flutter app, and points at parseplatform.org for the wider platform picture.

Semantic release with a monorepo plugin, and the tag names show it

The build tooling is worth looking at because it explains the version numbers you will encounter. The root package.json is named parse-sdk-flutter and carries a version of 9.4.0, and its entire dependency list is a set of devDependencies for the release toolchain: semantic-release itself at 25.0.8, the changelog generator, the commit analyzer, the exec plugin, the git plugin, the release notes generator, and semantic-release-monorepo at 8.0.2. That last entry is the important one, since a monorepo publishing two packages needs a monorepo aware release plugin to compute a version per package rather than one version for the whole tree. The release tags confirm the per-package scheme, with dart-9.7.0, dart-9.6.1 and dart-9.6.0 as the recent ones. The repository also carries a .releaserc directory and a release.config.js file, so the release configuration is committed rather than kept in a settings screen.

A versioning policy and migration guides are in the repository

Two files at the top level exist for consumers rather than contributors, and they are the pair to read before you upgrade. VERSIONING_POLICY.md states how versions are decided, and MIGRATION_GUIDES.md holds the guides for moving between them. Their presence is the answer to the question every SDK user asks, which is what breaking changes will do to my app. A package that ships named major versions, with a written policy and per release migration notes, is making a commitment to tell you in advance. The alternative, a package that bumps a number and changes a method signature in the same release, is worse in every way and much harder to plan around. There is also a CONTRIBUTING.md file linked from the readme, which asks contributors to make the process easy and transparent, and the repository is Apache-2.0 licensed with a NOTICE file alongside the LICENSE.

The community around Parse Server is broader than this repository

The badges and links in the readme point at a wider organisation than one repository. There is a Discourse forum for Parse Server, a Slack chat that is listed as a channel you can join, a Twitter account for the platform, and Open Collective badges for both backers and sponsors of parse-server. The Open Collective link is the interesting one for judging the project's continuity, because recurring donations to a specific project are a more durable signal than a one-off star, and the readme asks people to support the work with a monthly donation. The repository itself is part of the parse-community organisation and its topic list includes parse-server and parse-sdk, which is how the Dart client stays aligned with the backend it talks to. The build badge points at a CI workflow on the master branch, and a coverage badge points at Codecov, so the test coverage of the SDK is at least measured.

Using the SDK instead of calling the REST API directly

The alternative to this SDK is talking to a Parse Server over its REST interface with your own HTTP client and your own JSON handling, or using another language client. The difference in approach is the layer between your application and the network. A raw REST integration means you write request construction, session token handling, object queries with their constraints syntax, and error mapping, and you keep all of it when the server side changes. A typed Dart client means those concerns are solved once in a package that is versioned alongside the server, and your application code deals in Dart objects and typed results. The cost is that you take a dependency on the SDK's API, so the versioning policy and the migration guides become part of your upgrade planning, and you accept that the SDK covers the backend as the project defines it rather than as your application needs it. For a Flutter team already in the Dart ecosystem, that trade is usually worth it, particularly when the same Parse Server is also being consumed by a non-Flutter client written in another language.

Maintenance state and the gap between the tags and the manifest

The repository is not archived and the last push was on 2026-10-17, so the tree is being worked on. The releases are named dart-9.7.0 from 2026-03-29, dart-9.6.1 from 2026-01-25 and dart-9.6.0 from 2026-01-11. The interesting detail is that the root package.json still says version 9.4.0, which is a natural consequence of the monorepo setup, where the root manifest is a release tool container rather than a published artifact, and the individual packages carry the version that gets published to pub.dev. So the git tag, the published package version and the root manifest number are three different things, and a dependency pin in your pubspec should be made against the published package version rather than against a tag. The default branch is master, the topics list includes hacktoberfest, which is a hint that the project takes outside contributions, and the scripts directory at the top level holds the release and maintenance tooling.

Editorial conclusion

Parse SDK Flutter fits a Flutter team that wants to run its own Parse Server and talk to it from the app through typed Dart rather than hand written HTTP calls, and it fits a team that values a self-hosted backend with the wider Parse community behind it. It does not fit a team that wants a hosted product with a vendor accountable for uptime, and it does not fit anyone who upgrades casually, because the versioning policy and the migration guides are the mechanism by which breaking changes arrive. Before you adopt it, read VERSIONING_POLICY.md and MIGRATION_GUIDES.md in the repository, confirm which of the two packages your project needs, and check the release tag you are pinning against the package version, since the git tags and the published package versions are numbered separately.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. parse-community/Parse-SDK-Flutter on GitHub
3. Project website
4. README
5. Releases