That’s a good question which has been touched many times over the years in various threads.
It’s another aspect of the ambivalence of Parse Server. While Parse Server is designed to be accessible also for beginners, open sourcing it has increased the required expertise to run a production-fit app.
Generally, there are 4 performances areas to consider:
- database (e.g. queries, indices, data scheme, server resources, sharding)
- server (e.g. instance resources, disk throughput)
- app (e.g. parse server code base, nodejs specifics, parse server cache config, multi-core usage, disk ops, client - server interaction, custom cloud code)
- network / infrastructure (e.g. load balancer, network bandwidth between components, geo-distribution of resources)
Each of these areas has 2 dimensions:
- momentary performance (when everything runs fine)
- historic performance (considering downtimes, e.g. due to malicious attacks, misconfiguration, component failure)
Each of these fields can go deep into details, hence they are often allocated to distinct roles / teams in organizations. It can be challenging for full-stack developers and “one-person shows” to keep up with all these aspects.
I think it would make sense to compose a document over time that lists the “what I wish I knew when I started” things to consider for each field. It would be the logical document necessary to keep Parse Server easily accessible for beginners even as it is open source now.
There are obvious recommendations such as keeping database field names as short as possible, because it impacts data transfer costs when scaling. But there are many obscure aspects such as choosing a TLD with low DNS latency for the server endpoint, because it impacts connection speed from client to server.
Maybe you can begin by listing what you “wish you knew when you started” and others can add to that list easily here and we eventually compile a document as part of the Parse Server guide.