What you love about Parse? (and also of the difficulties you have encountered)

[Moumouls]

In order to help us to improve it and make it evolve in the right direction we would need some feedback from you!

What you love about Parse ?

• All In One Backend
• Auth features
• Rest API
• GraphQL API
• Documentation
• Parse Dashboard
• SDKs
• Security
• Cloud Functions
• Cloud Triggers
• Performance

What has caused you the most difficulty in using Parse?

• Securing Parse
• Documentation
• Rest API
• GraphQL API
• Parse Server Options
• Parse Server Deployment
• File uploading
• Cloud functions
• Cloud triggers
• ACL/CLP
• Consistency across envs
• SDKs
• Errors feedback
• Dashboard
• User Auth

Post in comments what we should improve !
Please we should avoid duplicates, prefer to like a similar comment !

[IlyaDiallo]

The thing that has caused me the most difficulty in not on the list: it’s the transition from V2 to V3. The API changed, breaking the existing code, especially Cloud Functions.

The maintainers have to acknowledge the fact that Parse is a core software upon which several layers of code are built. It’s OK to evolve the API, but carefully. - i.e. first marking the “old” API as deprecated when introducing the “new” API, then removing it in a next major version if there’s a manageable migration path. The V2/V3 transition is tricky because you have to update the server code and the Cloud Function at the same time, and the two are not even always maintained by the same persons or companies.

[Moumouls]

Thanks @IlyaDiallo for your feedback. We know that breaking changes are not easy to handle for developers. You are right; the deprecated policy is the best one; when breaking changes are introduced. Sadly, deprecated policy requires much more work for each feature (need more tests, requires more maintenance, etc…).

As parse server is not owned by a company or backed by a company directly; (which is not the case for example of Firebase, Hasura, Prisma and many others); parse server is backed by a team of open source volunteers who work mainly on Parse Server during their free time or when their company needs a new feature, this kind of policy is very difficult to implement in our context.

As a member of the open source team, I also hope like you that we will not have other breaking changes like the one between v2 - v3

[IlyaDiallo]

I agree with most of what you’re saying, and I’m glad that you share the concern about breaking changes.

What I’m not agreeing on is that it’s only a question of having paid people. It’s also, maybe mostly, a question of caring about compatibility and the consequences of breaking changes. For example, the spirit of deprecation is to give a warning about the future plans of the maintainers, in itself it’s not that big a burden - the inconvenience for maintainers is mainly to sometimes defer some changes to the next version.
And for Parse specifically, breaking changes to the Cloud API were not a necessity, it was for “cleaner” code, an interim version keeping compatibility would have been possible and far less painful for migration. It looks more like a “the maintainer doesn’t worry about it” issue than a “it’s too hard to keep compatibility” issue (I could be wrong though).

[zadek]

Here’s what I’d add to the list of difficulties: Contribution! I would love to contribute to the project, because I love what you all are doing and use Parse Server all the time, at work and in hackathons. However, I am not sure how to start contributing. I even found little issue to start working on (#6218) but gave up after running into a lot of obscure error messages when trying to develop and test parse server locally, which was discouraging. The developer guide could use some more detail, and some common errors could be discussed on there too. A link to the Slack or this forum would also help.
By the way, thanks for setting up the forum!

[Moumouls]

thanks @zadek for your feeback, we are aware the difficulty to onboard on the project and start to contributing @Manuel just opened an issue on the repo: Improve contribution guide · Issue #7100 · parse-community/parse-server · GitHub

We will appreciate your detailed feedback We are also open to proposal to improve the development developer experience on parse repos !

[dblythy]

I had troubles from V2 to V3 too, mostly because the documentation didn’t cover my use case. It was a tedious experience for me, but my code is a lot easier to maintain now.

@zadek I’m sure you’ve already gathered that you’re welcome to ask any of the core team for support when contributing. It can be overwhelming at first to work out what needs to be changed.

I’d be curious to hear any feedback around specifically documentation and error feedback difficulties, I’m willing to continue to improve the docs.

[Tom]

@Moumouls You might like to take a look at this thread on Twitter. I did encourage them to feedback on this thread but thought I would share myself incase they don’t.

[zadek]

I just did my first contribution with a colleague of mine and we weren’t really sure which guide to follow. There’s some information in the Parse Server Guide (Parse Server Guide | Parse) and in the GitHub repo (parse-server/CONTRIBUTING.md at master · parse-community/parse-server · GitHub), but the best one we found was on the blog (How to start contributing to Parse Server).
Maybe it would be good to move the information in the Parse Server Guide to the repo and link that?

[Manuel]

The most effective approach in my view is to transfer parts of the blog post into the official docs and merge the Parse Server guide on how to set up a development environment and the contribution guide into one.

The blog post is easy to understand mainly because it contains visual step-by-step instructions without assuming much pre-existing knowledge. However, as discussed, the blog post has a major disadvantage - it is a post by one author buried in a blog, not a community managed document that is part of the official contribution guide which is more accessible and more likely to evolve through contributions. The issue arising is - as your comment confirms it - if the blog post is currently the most practical document, it will be referenced and missing out discussion around improvement and contributions. That of course is not the blog post’s fault, but the fault of the current contribution guide which should be improved.

The blog post in fact originated from a discussion in an open issue to improve the contribution guide. While the blog post is a great anecdotal account in many regards of the challenges encountered when contributing, the transfer of an adapted version into the contribution docs (not a link) and adding more step-by-step information about debugging, etc would seem to have the most sustainable effect.