Is Parse a good alternative to Firebase?

Parse Server 📡
1

Hi, is parse server a good alternative to firebase? I am new to parse and I know facebook has stopped supporting parse. So, I want to hear people’s opinions. Thanks

1 Like
2

It may not offer all features of Firebase, but once you spend some time learning Parse and setting it up - which may not be always so easy and polished like Firebase, you will own it.

And that is the biggest plus. I have been through 5 major companies killing 5 major dependencies of my little app over the past 10 years, that was like one major migration every two years.

So if you are serious about your idea, do not go with Firebase, if you want to just get something quickly up and running, then yes, Firebase may be quicker and more polished in the beginning, but becoming a time bomb in the long run.

Just my .2 cents,
Martin

2 Likes
3

I use parse server for the last few years.
You can easy build beautiful apps in no time. The only thing is when you host it by yourself and don’t have the “DevOps” Knowledge about Docker or whatever you want to use.

There are several BaaS outside you could use and test for a quick setup.

1 Like
4

In addition to this, parse server (MongoDb actually) has a very powerful query language. I was using firebase 2 years ago. I was using realtime database but queries was pain in the ass. They later solved alot of problems with firestore but it’s still can’t get close to parse.

1 Like
5

Thanks for anyone’s kind response. After the facebook stopped supporting parse, has the community added many features to parse? Also, should I use GraphQL with parse? Thanks

6

Yes. A lot of feature has been added including the GraphQL support, which is fully operational.

7

Thanks for the warm welcome and answers. I have decided to give parse a try!

2 Likes
8

Great to hear @hkblue!

As Davi said, lots of features, to many to list! - but they are all listed in the Parse Server changelog - almost all of which is since the departure of FB.

Just to pick out a few recent features (some yet to be released)…

  • Parse.Cloud.sendEmail(...) - convenience method for sending email in Cloud code, thanks to @dblythy!
  • Ability to add localised password reset and email verification pages, thanks to @Manuel!
  • Cloud Validators - see documentation here, thanks to @dblythy!
  • Idempotency enforcement - see documentation here, thanks to @Manuel!

Aside from Parse Server there have also been many improvements to our client SDKs. Including the addition of new ones such as the Flutter SDK written by @phillwiggins, our brand new Swift SDK thanks to @cbaker6 and the new experimental React & React Native packages thanks to @davimacedo.

2 Likes
9

@Tom Thanks for pointing out the new features. I am super excited now!

1 Like
10

Our goals are also to make Parse Server as complete as possible, so if there are any features which you feel like we’re missing, feel free to let us know :slight_smile:

11

We are in the same boat as OP and considering the move from Firebase, mainly due to challenges with Google banning services in certain countries and being banned in some of the bigger markets such as China.
Can I kindly ask those who moved from Firebase + Firestore to provide insight as to what their experience was? What was unexpected coming from Firebase toolset and what was a pleasant surprise?
Thanks in advance

12

I have inherited an application based on parse a few weeks ago, I can share my experience with platform so far.

Documentation
There is a lot of documentation, thats good. It can be hard to understand what parse is capable of, since features can only be available in one SDK and not the other. Since there is no “general sdk client” guide I have basically jump through all client SKD documents to understand what is described.

Example from the docs:
“To make it super easy to create user-private ACLs for every object, we have a way to set a default ACL that will be used for every new object you create:”

  • js/guide/#access-control-lists → // not available in the JavaScript SDK
  • /rest/guide/#object-level-access-control → // REST client: code snippet not even rendered, you will be confused if you read this the first time
  • /unity/guide/#object-level-access-control → // // not available in the .NET SDK

for the parse server you also need to check with two sources, since not all info is available in one or the other:

  • githubcom/parse-community/parse-server
  • parse-server/guide/

Authentication & identity
There are many adapters for identity providers, however the we need to implement multiple identity platforms for different tenants. We struggle to understand how the authentication flow is supposed to be with an custom authentication provider. There is a little bit of information on many places:

  • /parse-server/guide/#custom-authentication → server side
  • /js/guide/#linking-users → js client side
  • check the jasmine test case
  • check the source code

Every section explains a little bit, but there is no clear high level picture how the flow should be and it is a lot of trial and error to understand the code flow. If you search google and the forum that questions are asked repeatedly about how sessionTokens are supposed to work, how “linkWith()” is supposed to be used.

Security
Everything is allowed and enabled be by default. This is good for development purposed, but poor from a security standpoint. Since by default everything is allowed you have to be extra careful about locking down your app, not slipping config errors to production and creates a attack vector. I suggest when you start developing lock everything down / deny all from the start and enable it when you you need it, since deny all will create much less opportunity for security holes.

Client centric view
The documentation is written around the idea that all business logic is centered in the client. I need to support features to multiple clients (mobile, web, REST) which means I have to duplicate the business logic “e.g. list all active users” multiple times within each client. Currently I have to evaluate if I can migrate the code from the clients to Cloud Code functions.

Market outlook
Parse has an active community and at least one business offering commercial support. On a market view every big cloud vendor invests in its mobile dev framework (AWS amplify, Google firebase, MongoDB realm/stitch, Azure Mobile Apps). Each vendor has their own issues and you get the benefit of highly integrated services, with a steep learning curve. Open source projects with no vendor support struggle about continous support, e.g. lasts year when the core maintainer of hapijs quitted and the future path of that project was unclear.

Note: Had to remove links because “Sorry, new users can only put 2 links in a post.”

13

@Tom some good doc feedback here

14

We are on the path to gradually change these settings to be more strict by default. There has been some pushback with the argument that new developers may find it difficult to “play around” with Parse Platform. I do not share that view and your feedback once again confirms that Parse Server has to be secure first and foremost, before being a programming 101 playground for new developers.

There is a PR in the works that will log (and eventually show in the Parse Dashboard) weak security configurations. It still has some conceptual issues but should be finished soon. This feature should provide a significant improvement in this regard. Feel free to join the discussion there and provide feedback.

1 Like
15

I recently finished re-prototyping a product that used to use Firebase.

The reason I switched was because - no search. Or poor search anyway. Yes, I did use the Firebase Functions to monitor changes for data and yes I did copy ALL the data to Mongo so that I could actually run a capable search … but the overhead is TOO HIGH. I shouldn’t have to mirror my data and maintain those bridges (and support customers when the triggers fail to fire - yes, it does happen). And the permissions system in Firebase plain sucks IMHO. ACL is much more powerful and IMHO simpler.

So I switched to parse to have an all-in-one - but here are the two main ‘gotchyas’.

  • Parse can be finiky when working with nested data (setting and getting nested paths), which Firebase is really strong at, so you might might need a mental shift and data restructure here. It seems to want flat SQL like data but I’m a Mongo guy - I like nested data because to me its cleaner and more organized.

  • Data reactivity. It’s non-existant in Parse. If you are used to binding data from Firebase to a Vue or React-type application and having changes magically reflect through your application when the data changes from the view or a central store (eg vuex), it’s not going to happen. Getting anything is a get() function which cannot be bound to reactive UI libraries … or proxied.

Frankly, with the popularity of Vue and React and such, I’m very surprised that the Parse community hasn’t created any reactive view of the underlying data.

In other way, Parse is a dream! Data modelling, relations, ACLs, cloud functions, and serach. Plus it can be self-hosted or commercially hosted from a variety of options (I choose Sashido.io). Its a great option!

16

That makes me think, how about adding a feature comparison table in the Parse Server README on GitHub?

17

I am wondering if you are going to provide phone authentication and map services in PS

18

You can accomplish this with LiveQuery (this has been around for some years, pre 2017 I believe. If I recall correctly LiveQuery was announced around the same time Firebase announced they were using Websockets, which is what LiveQuery uses) which is available in Android, Flutter, JS, iOS, ParseSwift, etc. SDKs. Though I don’t know much about Vue, @dblythy and I mentioned this here, seemed similar to SwiftUI from my understanding. From a programming/SDK perspective, you should be able to bind your model (Parse Server Database) to any view. There’s a simple example of doing this in the Parse-Swift SDK in Swift Playgrounds:

Essentially, in Parse, when your view first comes on screen, you can run a traditional find/first/get query to “pull” your data from the server. Then, you can “subscribe” to that query (assuming you have LiveQuery enabled) and bind that to your view to react to any changes on the server.

1 Like
19

Parse allows nested paths in a few places. Can you let us know where you seen finicky behavior? There is a pending fix for exclude in this PR, but using paths with select and other types of queries should be working well.

20

I’m not sure what you mean (feel free to explain more), but @moumouls is working on major updates to the Auth adaptors which will allow for 2FA via TOTP and SMS. Keep an eye out!