Parse-server: Will Postgres be a first class alternative?

[kulshekhar]

I've been trying a bit to get parse server to work with Postgres and have a few questions regarding the utility of this (and future) effort:

• Does the core team think Postgres can become a first class alternative to MongoDB in parse server? (If not, just ignore the rest of this and close this issue)
• Could you please lay out a roadmap/issue list/specs, addressing which could achieve this? (it's difficult for someone not familiar with the existing codebase to do this)
• Would there be support for a new API that supports transactions (and possibly others that can leverage Postgres's capabilities)?

I don't mean to ask whether the core team will implement all of this. What I want to know is:

• whether the core team would like parse server to take this direction
• whether it is willing to lay out specs/issues that make the path to implement all these features clear

[flovilmart]

whether the core team would like parse server to take this direction

YES! Postgres is a first class citizen, that's why this adapter code is in parse-server and not in an external adapter.

whether it is willing to lay out specs/issues that make the path to implement all these features clear

There is no roadmap so far, the main focus would be stability, and reliability at first, performance next.
Then special use cases, BUT, without cluttering too much the common code. I'm open to all ideas coming that way. The same way, we have a few tricks for mongodb, we can have a few tricks for postgres.

What do you think?

[kulshekhar]

YES! Postgres is a first class citizen

That's good to know :)

There is no roadmap so far, the main focus would be stability, and reliability at first, performance next.
Then special use cases, BUT, without cluttering too much the common code. I'm open to all ideas coming that way. The same way, we have a few tricks for mongodb, we can have a few tricks for postgres.

What do you think?

This sounds right and it makes sense. The thing is, as someone looking at this from the outside, I have no idea how can I translate this into some actionable tasks.

One step was to go through mongo specific tests and try to get them to run against postgres. Some of the tests were converted and some of the remaining ones seem like they'd be specific to MongoDB. I have already been able to use the dashboard with Postgres.

At this stage, I don't know what to do to next. If it were left to me, I'd probably start building in transaction support (because my app needs that). Then I'd start building my app using parse server and postgres. And during development, I'd work on fixing the postgres specific issues that I'd run into.

As you can see, my decisions (I'm only taking myself as an example here) would be driven by what my app needs. So if there are some features that I don't need, I won't realize about the stability/reliability issues related to that. I'm not sure you want parse server to be developed in that manner.

On the other hand, given that

• there aren't many people using parse server with postgres and
• there is no roadmap/guidelines on what needs to be done to achieve stability/reliability

I think it might be faster to implement new features (especially transaction support) and then improve reliability/stability/other bugs as they become apparent with increased usage.

[flovilmart]

As you can see, my decisions (I'm only taking myself as an example here) would be driven by what my app needs.

And that's great, if you have a need that is 'general' and not introducing special cases that could be implemented differently or outside.

I'm not sure you want parse server to be developed in that manner.

We all use specific areas of parse-server, and we can't possibly work on everything at once. If there is a particular improvement your want to bring, go ahead. The rest will follow.

Focusing on stability and performance just means that when a user reports a stability/performance issue, we prioritize those errors first vs the new features. Meaning we'll try to provide a fix in the next release.

At this stage, I don't know what to do to next. If it were left to me, I'd probably start building in transaction support

If at this stage, the dashboard is functioning correctly with the postgres support, then move forward with transaction support! We'll likely find new problems along the way.

I don't mean to ask whether the core team will implement all of this.

You are a maintainer now, you're as good as any of us to show the way forward for that particular project ;)

Does it make sense?

[kulshekhar]

That sounds good.

So for something like transactions, is there a formal process I need to go through before it can be worked on? Should I create an issue with an explanation on how I intend to go about it (for early feedback) or should I implement it, submit a PR and then see if it is acceptable?

A somewhat unrelated question - if I have questions about existing code, is there a specific chat room (gitter doesn't seem very active) or forum where I can ask them or should I do that here via GH issues?

[flovilmart]

is there a specific chat room

Shoot me a mail I'll get you in

is there a formal process I need to go through before it can be worked on?

probably outline how you would go about it before in https://github.com/parse-server-modules/parse-evolution (open a PR with the template in the proposals folder), that will help with communications.