Should we direct questions to Server Fault?

@mtrezza I should have been more clear in that I meant that we should suggest all questions not appropriate for SO to be posted on the forum rather than suggesting some go to Server Fault.

Inappropriate questions definitely shouldn’t be directed to SO as that doesn’t help our community if they just get closed - even if they often don’t it still doesn’t help the SO community. Equally directing some questions to Server Fault where on the parse tag there is a low existing knowledge base and questions are unlikely to be answered by the Parse Community.

Thoughts?

1 Like

I’d redirect to Server Fault deployment related questions, like how to setup a reverse proxy, how to horizontally scale push notifications, etc…

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.

Some ideas:

  • 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 to parse-platform and add parse-server as a synonym, to make it equal to SO.

I have removed ServerFault from my templates until we reach a decision on whether we want to refer to it. If we decide to not refer to it, I will remove the SF references from the recent comments. By being more vocal about the places to post Parse Server questions, we can let the parse tag “die” on SF, there is a periodic script that removes unused tags. There are also only 60 questions, so if we remove the tags manually, it will just disappear in a few days.

For reference, a tag discussions and my initiative from last year to merge tags on SO. ServerFault is part of the discussion.