Using Parse Server in production

[zeluspudding]

So this isn't really an issue but a question who's answer is probably good to know for a lot of us. Stemming from the implications of #1057 I'm wondering if ParseServer is ready for thin (or even fat for that matter) client applications. If this is not the appropriate place to answer this question, please, by all means reply to this (not my) post

[tobernguyen]

I'm. But honestly, it is really unstable. I have had to switch back to Parse.com 3 times so far. So many unknown problems happened and I can't even reproduce it. My setup:

• Hosted mongoDB at mLab: Shared Cluster
• Two VPS running Parse Server
• One VPS for load balancing to 2 above server
• Background job processing with Kue and Redis
• NewRelic for performance measurement and Airbrake for exception notification.

[FridaySG]

+1. Would like to hear some more feedback from a reliability standpoint before adopting myself too, especially from the majority who set it up with the recommended/basic implementation. These guys have been working crazy hard on it. Every time I check out this git there's a commit made just a few hours ago, and with the added features at this point parse-server has superseded it's predecessor.

[bohemima]

TL;DR - Wait with parse-server for at least 2-3 months, let it mature first.

I quickly jumped on the train here, been following pretty much all commits, issues, PR's, etc.

The very first thing you'll notice is how easy it is now to run and debug cloud code locally, this is one of the major improvements we get now.

Stability - I'd stay put for a while, there is no rush yet. You definitely want to migrate your database before the end of April, as the migration docs hints about lower priority for their own mongodb instances.

Following the migration docs, the next "important" date is July 28th, where you are supposed to switch to your own hosted parse-server. The migration docs are pretty spot on and very well written. Read it carefully.

[omairvaiyani]

We've switched to parse-server on production, but mainly because our platform is still in beta ~500 daily users. It's stable enough most of the time, but there seems to be a disconnect between the level of activity on parse-server vs. parse-sdk-js; we often find issues with the client-side code arising after updating parse-server. Overall, the issues have been balanced by the ability to test cloud code locally. The lack of timeouts is a massive bonus.

[davimacedo]

In back4app we have now about 500 apps running in production with Parse Server running in our infra-structure. Honestly most part of them are very simple applications. At this moment, I think that Parse Server is not 100% prepared for existing complex applications. The complex ones still suffer in the migration process mainly with features related to Jobs, Push Notifications and Cloud Code Hosting. BUT I really believe that in a little time Parse Server will be the best framework for API and backend development. We have just to keep working hard and focused to make it real: app developers sending bugs/issues, parse server developers improving the framework and parse hosting services improving tools to make it easier for developers.

[flovilmart]

what @bohemima said! There is no rush to migrate to parse-server. In the meantime, before July 28th, it's maybe a great time to train your team in deployments, shell scripts, collecting logs from cloud providers, find the provider that best suits you etc...

Use that time to have a good understanding of what you're leaping into, from a fully managed backend to a backend that you manage.

Read on best practices on deploying express apps, do testing on small apps, get familiar with the code base, the inner workings etc... As the code is open-source this doesn't mean you'll ever have full time engineers to fix/patch the problems you face.

Post issues, pull requests, that's one of the best ways to get familiarized with the source.
In the end, even if you deploy to back4app or anywhere else, you'll need to understand why sometimes things don't work as expected.

Keep in mind, that this code, as being open-source is provided as-is. There is nothing forcing the contributors to work on the bugs you discover.
The core contributors are mostly here to ensure feature parity is achieved in a reasonable time frame and make sure the quality of the code in the pull requests match the requirements for such project.

[flovilmart]

@tobernguyen that would be nice if you managed to repro those problems, that would be valuable information for many users

[zeluspudding]

These comments help frame what should be a reasonable schedule for getting parse server into production... I know, at least for me, it will be somewhat longer than originally desired.
That's OK.
The team that's come around the project thus far has done wonderful work! Thank you all for your input - it really does help.

[corbanb]

@tobernguyen would you be able to share more on how you setup the background jobs with kue and redis?

[carmenlau]

Would like to ask you guys after you migrate to the new parse server, will you keep your old app running with parse.com cloud code? During development, I found some backward compatibility problems. Like parse.com and parse server are using different fields for ACL. The old app are not able to get the images from new s3 buckets...etc.

[FridaySG]

@carmenlau You should document those problems and open up some issues with logs if you can please.

[alexrmacleod]

@omairvaiyani how did u get 500 daily users in beta. i cant even get 100 in my latest production release

[omairvaiyani]

@alexrmacleod i don't think that is relevant to parse server but for your curiosity, it's an educational platform and we have a wide reach from our previous product.