I understand the concerns that directing questions to a forum where one is unlikely to get an answer wouldn’t make much sense, but I challenge the assumption, that a network related question would not get appropriate attention on SF.
According to SE guidelines:
- The appropriate place for code-level questions is SO.
- The appropriate place for server/network questions is SF.
The questions that should go on SF are not so much Parse Server related, they are server and network related. The challenge for the author here seems to be phrasing the question correctly to get an appropriate answer. That however requires some understanding of the problem, which is the actual issue in the first place. The
parse tag is just a side info. From my experience, network related questions also get appropriate attention on SF, when properly formulated.
I once took the time to explain http server timeout settings in a Heroku context, but only because it is a fundamental setting that is not in the Parse Server docs (rightly so), and someone new to the topic will have to deal with it once their traffic scales. I wrote the answer in detail because it is a common issue when running Parse Server on Heroku and so we can point to it in the future.
Here is another Node.js http server question that asks about timeout of Parse Server. I can see this as a Parse Serve question as far as how to set the timeout, but the answer to set the http server timeout is only scratching the surface of request / keep-alive timeouts and how they have to be aligned up- and downstream to not produce other errors. Once the OP sets the timeout, they will likely come back with errors they suddenly encounter up/downstream. That I wouldn’t see as a Parse Server question anymore and I would refer to SF.
Here is another question that in my opinion is unrelated to Parse Server beyond a general Parse Server performance example, pointing to the DB as a potential bottleneck or suggesting NewRelic. It could be a variety of reasons why the author can’t get more req/s, from nginx configs, to CPU usage on the host, to host port limits, to file descriptor limits, etc. This would be a classic SF question.
I think that is somewhat the dichotomy of hosted Parse vs. open source Parse. We try to make Parse Server accessible and abstract away the complexity of mBaaS, but once it is self-hosted, there are new contextual issues that are not product related.
Add a support document where we collect the most common contextual / network / technology questions, so we make our lives easier because we can refer to it and the author’s life easier, because they get a quick answer, hopefully before even asking. Like what are the main environment config issues running Parse Server locally / on Heroku / on AWS in Elastic Beanstalk; what to consider when setting the Parse Server timeout, etc. Beyond that I would categorically point to SF / SO and close the case.
Change the SF tag from
parse-platform and add
parse-server as a synonym, to make it equal to SO.