Re: Proposal for an Emacs User Survey

[Philip K.]

Adrien Brochard <abrochard@gmx.com> writes:

>> For the fun of it, I wrote a simple survey application[0] that includes
>> a self-hosted captcha (without tracking anyone), requires no Javascript,
>> is mobile friendly and should be fairly fast. Of course it can be
>> improved. I wrote it as a quick and dirty evening project, but I
>> think it demonstrates that this kind of an approach is practicable.
>>
>> [0] https://git.sr.ht/~zge/survey
>
> Thank you! I really like reading go code (no sarcasm).
> It it clear that this approach will work but the remaining 20% are the
> hardest.  I'm concerned with:
> - cleaner UI, not just HTML embedded in the code

What would you have in mind? I know that my example is simple, but I
prefer that to sites that take forever to load and reload everything all
the time, for no apparent reason.

> - mysql instead of sqlite, which also implies a mysql instance running

SQLite is actually surprisingly resilient, according to [0]:

> SQLite works great as the database engine for most low to medium traffic
> websites (which is to say, most websites). The amount of web traffic
> that SQLite can handle depends on how heavily the website uses its
> database. Generally speaking, any site that gets fewer than 100K
> hits/day should work fine with SQLite. The 100K hits/day figure is a
> conservative estimate, not a hard upper bound. SQLite has been
> demonstrated to work with 10 times that amount of traffic.

But either way, I used sqlite to avoid setting up a RDBMS.

[0] https://www.sqlite.org/whentouse.html

> - DOS protection, maybe some rate-limiting and IP blocking
> - HTTPS, thankfully it's easier now

AFAIK these things can usually be handled by a frond-end such as NGINX.

> - monitoring, how do we know the service is running as expected
> - logging, and how to store logs for debug

If there is any interest, extending the example to support this would be
feasible. The "20%" you mention aren't easy, but from what I see it
shouldn't be too hard either.

> My greatest fear is people clicking on the link, filling out the form,
> trying to submit, seeing an error page, and never coming back to it.

The reason I suggested using a simple HTML form and implemented the demo
was because I think simplicity helps avoid a lot of issues. With fewer
dependencies, secondary services, modules, etc. the chance of one of
these failing decreases. And having a smaller footprint should also
reduce the network load.

> Best,
> Adrien

-- 
        Philip K.