Parse server with dashboard.

[jdaviescoates]

@atrilahiji see also https://supabase.io/

[A Former User]

@jdaviescoates This honestly would be incredible. I would be intrested in using that + a dedicated backend. I guess what I really want is the ability to use Cloudron as a platform to let me spin up DBs for realtime applications. Of course Parse was something I wanted because of the serverless functions.

[jdaviescoates]

@atrilahiji I'm not a developer so it's all a little over my head to be honest, but I just saw a thread on social.coop about "what FOSS app do you wish existed?" and someone said they'd like an open source Firebase and then someone else pointed to supabase and so I came here to see if anyone had written anything about either

[jdaviescoates]

@atrilahiji but I guess maybe add Supabase to the App wishlist? (although it seems pretty new and so possibly not self-hostable yet?)

[timconsidine]

Anybody attempted building a package for Parse using Postgres ?
The default DB is Mongo but they support Postgres.
As Postgres is on Cloudron, maybe Parse Server could be installed.
Seems it is just node.js

I have been running a hosted Parse server, but would love to be self-hosting on Cloudron.

[timconsidine]

I have made a custom package for the parse server on Cloudron using mongodb.
In order to get it working, I had to use cloudron base image 4.3, so it may not be AppStore acceptable.

At this stage it is just the parse server, which is accessed programatically by another app.
But it is still useful.
I currently have a selfhosted instance of Parse using docker compose but I would prefer it in Cloudron.

Next step is to package the parse dashboard so that there is a better UI.

Once that is done, I will make a repo available.

@staff what’s the status of cloudron base image 4.3, and 5.0 for that matter ?
It would be good if they can be used as they seem to resolve some node issues when packaging apps.

[girish]

@timconsidine feel free to use whatever base image works for now . At publish time, we can adjust the base image. Base image 5 will be the next one and will be part of Cloudron 9 (which we hope to release end of next month).

[timconsidine]

Thank you @girish

Parse Server is quite extensive, and my first package might be ‘basic’.
I tend to need only the core functionality, not all the ‘bells and whistles’.
Could those interested in using Parse Server please chip in with comments about what features of Parse Server they are likely to want, so I can check those and try to include (no promises!)
For me the Parse Dashboard is the next “ add on” but I can look at other stuff.

[timconsidine]

Parse Dashboard now packaged and runs with Parse Server

I need to do some tidying up of the build steps and the default configuration, and some more testing, and will then publish a repo for each on cloudron git.

I decided to keep them as separate apps, because :

• that’s how the source repos are structured (maybe this will help with upgrades etc)
• conceivably some people will not need the Dashboard, relying on programmatic access only and their own node/whatever app.

Both apps are packaged with cloudron base image 4.3 (can be changed of course).

[timconsidine]

I have uploaded my custom packages for Parse Server and Parse Dashboard.

~~https://gitlab.fo1.uk/timconsidine/cloudron-parse-server~~

~~https://gitlab.fo1.uk/timconsidine/cloudron-parse-dashboard~~

https://git.cloudron.io/timconsidine/cloudron-parse-server

https://git.cloudron.io/timconsidine/cloudron-parse-dashboard

I would describe these as BETA releases.
They work for me, but I cannot claim they have been fully tested.

Dummy credentials are in each app’s config files under /app/data.
Unsurprisingly they should (a) match in each app, and (b) be changed from their defaults !!
Then restart both apps.

Packaged as separate apps, because (a) that’s how the source repos are structured, and (b) Parse Dashboard is optional, only needed if you want some level of UI to the server instance.

A lot of interest has been expressed in having Supabase packaged for Cloudron, and indeed that was my first choice as an alternative to using Firebase.
I started with hosted Supabase, then moved to a self-hosted Supabase instance running via docker-compose, but gave up on packaging Supabase for Cloudron as it is intricate with multiple components.

Parse is, in my view, a no-less-effective alternative to Firebase, but it is much simpler to deply and use.

[girish]

@timconsidine have you looked into how backups work? Is Parse a database of it's own or does it use postgres/mysql ? Your repo shows a sign-in page btw , so I cannot check what addons it uses.

[timconsidine]

@girish I’m on the road so can’t check easily but think it’s mongodb
Will check asap

Will fix the repo so it’s viewable - sorry

[timconsidine]

@girish

Ah yes, backups !
Sorry, no, I haven’t checked how backups would work with the packaged app.
But it’s using the mongodb addon so hopefully it is compliant.

Extract from CloudronManifest.json :

"addons": {
    "mongodb": {
        "oplog": true
    },
    "sendmail": {},
    "localstorage": {}
},

About the repo visibility :
Oooops, the gitlab is my own dev one.
Sorry, I should have put in git.cloudron.io !!
I have temporarily made the repo public, but I will fix this by creating a repo for Parse Dashboard and Parse Server on git.cloudron.io later today.

[girish]

Yes, I think if it uses mongodb, it's all good!

Looks great, but if it's possible, we should merge the apps into one . Maybe the dashboard can become httpPorts or multiDomain flag ? This way it can have it's own subdomain . I think it's best to have some UI pre-installed!

[timconsidine]

@girish good news on mongodb

Yes, my first instinct was to have them packaged together.
But thinking it through, I thought maintenance and updates would be easier if the app packages followed the source repos which are separate. Otherwise we are merging source repos, which is unknown territory for me at least.

The other consideration is that Parse Dashboard is fairly limited.
It does provide a basic interface, maybe useful for initial configuration of a Class (in Parse terminology) or viewing all Classes in an instance.
But the typical user of Parse Server will be accessing it programmatically as a non-firebase backend for a web app (or in my case a mobile device app). I could predict that such a user would see minimal benefit of Parse Dashboard and wouldn’t want the overhead in the app of something they’re not using.

I can take a look at packaging both repos as one Cloudron app, if you think that would be better after considering the issue of updates from source repos.

[timconsidine]

Apps on git.cloudron.io :

https://git.cloudron.io/timconsidine/cloudron-parse-server

https://git.cloudron.io/timconsidine/cloudron-parse-dashboard

[timconsidine]

@girish another consideration about one app for both server and dashboard is that AFAIK the server app runs a single server instance whereas (in theory at least) parse-dashboard can connect to multiple server instances. I have not added that capability but it might be relatively straightforward.

In that scenario it might be little odd for the dashboard to be in a server instance for one server but connections to server#2 etc are in other instances. Messes with my brain anyway .
Keeping them as separate apps would allow a cloudron deployment of say 3 server instances as individual apps and one dashboard instance as a standalone app connecting to the server apps. Not if sure “scalability” is the right word but it’s something like that.

My opinions are not set. Just following how others seem to do it outside of Cloudron.

[girish]

@timconsidine good points . I would say let's not merge it (yet). Never used parse, so I have no idea about the usefulness about the UI. If there is no alternate dashboard, it does make sense to merge it. People can always disable it. I will take some time to evaluate parse next week or so. Will update! Let me know if you need anything on cloudron gitlab to push the repos.

[robi]

It may not matter, but I prefer this running on Postgres for longevity of support (currently 2029) and integrations from there.

The dashboard uses Postgres too.

The dash I think should stay with the package for completeness of one instance, as all the auth to the server happens there too.

Perhaps have an option to disable it on multiple instances, but then one doesn't have to use it and still configure all the auth across servers.

[timconsidine]

Update : I noticed that Parse had new versions, so am trying to package those.
However Parse has made some security changes which mean the initial approach of mirroring Parse Server and Parse Dashboard as separate apps doesn’t work.
So I am back to building a “mono-app” with latest versions of Parse Server and Parse Dashboard in one container, which has some advantages.

Focus on using MongoDB but perhaps could do Parse-Mongo and Parse-Postgres as an option after getting the new versions app working. Naively perhaps, but I’m assuming that Cloudron could make alternative db backend easy.