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.
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
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).
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!
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.
@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.
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.
