Evolve Example package

[dblythy]

Some ideas for evolution of Parse Server example:

Have multiple branches, with different levels of complexity, such as:

• [x] dev - the most simple Parse Server
• [ ] cjs - commonJS version of Parse Server
• [ ] prod - a Parse Server with some recommended user triggers, allowClientClassCreation, etc
• [x] AWS Secrets - a Parse Server utilising a secret manager
• [ ] definedSchema - Parse Server with defined schemas (@sadortun your input would be welcomed here)
• [ ] typescript - Parse Server with Typescript
• [ ] react - Parse Server with a react frontend
• [ ] vue - Parse Server with a VueJS frontend
• [ ] dashboard - Parse Server with a Parse Dashboard
• [ ] graphQL - GraphQL Parse Server
• [ ] cluster - Parse Server with clustering

[sadortun]

@dblythy excellent!

1)

I already had in mind making a Parse/Vue (2/3)/Typescript boilerplate project that uses Schemas and a few triggers.

I already have a project I can strip that have everything that can be used as a demo.

2)

I also really would like to see a clearer separation between the startup of ParseServer, Express and what's actually configurable. I think the Example project should be more organized/structured.

3) To keep things simple, I would see the project structure like that :

/common/models
/api/src
/api/src/schemas
/react/src
/Vue3/src
.....

It would help new users to get onboard of they would have the basic structures laid out and only have to work on their architecture.

4) ParseServer should be secure by default. (no exposed data) it might be a slight inconvenience for new users to explicitly have to specify what's public, but it can avoid bad usages and mistakes.

[dblythy]

@mtrezza and I discussed possibly using branches or specific folders so each individual branch only has files that are relevant to it. Our concern is that we don't want to overwhelm users with unnecessary complexity, unless they go looking for it.

I also really would like to see a clearer separation between the startup of ParseServer, Express and what's actually configurable. I think the Example project should be more organized/structured.

I agree, perhaps ParseServer options should be it's own file? export config = { "appname": ""}

ParseServer should be secure by default

I also agree, however Parse Server historically has always had the philosophy of being easy to use first and foremost, and secure thereafter. An example of this is allowClientClassCreation. If this was on by default, developers would get the hurdle when they first get set up of "I can't save anything because this stupid option". That's why I would foresee a branch with more complex options (such as securityChecks as well), that helps new users migrate from the development environment to the production environment. Being "secure" in a production environment, yet easy to learn in a development environment are two seperate challenges.

If you would be willing to collaborate on this, that would be fantastic. Ideally I would like to evolve the test page to have a user signup and login, and a simple TestObject save and fetch. I would like the test page to be written with the native SDKs rather than complicated code which has no practical application.

[sadortun]

"I can't save anything because this stupid option"

Lol! Indeed ! I would name an option like playground or something similar that have loose permission, but a clear console warning DONOT USE "PLAYGROUND MODE" IN PRODUCTION

If you would be willing to collaborate on this

OFC! 🚀

[mtrezza]

ParseServer should be secure by default.

I agree and that can only be addressed in the Parse Server repo, not the example repo, because that's where defaults are defined.

The example repo has the purpose of a playground to kickstart development, helping developers to get familiar with Parse Server, and demonstrating some use cases, so it is fine to pre-set insecure options for that.

To remind developers to not use insecure option in production environments - whether they built upon the example repo or not - we have Security Checks and a security best practice page in the docs. Hence, maybe a more cohesive experience than using a distinct "secure options" branch could be a simple reminder to look at those 2 before deploying for production. For example, add it to the example docs and/or hard code a log warning into the example repo.

This way we strike a balance between

• making the playground accessible without having to deal with restrictive settings
• mitigating the risk of insecure options being carried over from example to production

I also really would like to see a clearer separation between the startup of ParseServer, Express and what's actually configurable

Maybe a CLI can help with that and pre-set Parse Server example repo for a specific experience. It could set up Parse Server to use a specific cloud code source file depending on what a developer wants to experience. It could also go beyond that and install dependencies, change package.json entries and much more, so it could be a really versatile tool. @dblythy as the CLI expert probably can speak better to that than me 🙂

[dblythy]

I agree and that can only be addressed in the Parse Server repo

Maybe this could be the benefit of moving towards restrictive defaults, and then defining them in the "insecure" position in the "dev" branch. This way developers can still use Parse Server, and insecure options will only happen if distinctly set. So that migrating from dev to production requires keys (such as allowClientClassCreation) to be removed, rather than for them to be set.

Maybe a CLI can help with that and pre-set Parse Server example repo for a specific experience

The CLI can do what we want it to do, although it will require some cross-platform testing. It's going to be a good tool that can really help iron out some of the complications of getting started.

[mtrezza]

So that migrating from dev to production requires keys (such as allowClientClassCreation) to be removed, rather than for them to be set.

Yes, and regardless of how options need to be changed, the Security Checks should detect that and guide the developer. They were designed with that purpose in mind.

[dblythy]

Also - should the additional branches default to module syntax, or commonjs?

[dblythy]

Perhaps we should delete these outdated branches as well

[mtrezza]

I cleaned up old branches in dashboard today and found that some of them may include contributions from years back, but may still be relevant today. So before deleting the branch I opened a PR for discussion and to preserve the effort that went already into the code.

Another question, should parse-server-example repo have releases? There have only been 2 releases back in 2016. If we do releases here, then we would likely move this repo also to release automation. But then we may have to give up some liberties when it comes to branches, because release automation somewhat determines the branch model. That may be an argument against branches and for code modules.

The other issue with multiple branches is that snyk / dependabot may need to be configured to monitor each of the branches separately, at least if they contain different dependencies. That could lead to diverging branches, which can get quite complicated as we know from our current long-term support trial with parse server. Maybe another argument against branches and for code modules.

[dblythy]

The other issue with multiple branches is that snyk / dependabot may need to be configured

Hmmm, perhaps we could instead have multiple folders, with each folder the relative example. That way people who aren't familiar with GitHub branches can easily explore the examples, and snyk / dependabot can watch the folders.

[mtrezza]

Yes, snyk / dependabot watches branches. To make sure that works, a CLI for example should not modify package.json to create a user-specific version of the parse server example. So one condition may have to be a CLI script should not modify any dependencies in package.json, which has to contain all required dependencies for all example variations.

[dblythy]

I have also added a recommendation for a cluster branch - or should this be included by default? Shouldn't all the examples utilize multiple threads?

[parse-github-assistant[bot]]

Thanks for opening this issue!

• ❌ Please edit your post and use the provided template when creating a new issue. This helps everyone to understand your post better and asks for essential information to quicker review the issue.