[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for an Emacs User Survey

From: Adrien Brochard
Subject: Re: Proposal for an Emacs User Survey
Date: Fri, 9 Oct 2020 15:52:22 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Thunderbird/82.0

- 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.

The most obvious reason to me is that user error handling is pretty
poor. Because there is no JS, we cannot offer front-end validation, that
means that the backend server is responsible for validating fields
submitted. If validation does not pass, the page must "reload" for the
user and it needs to show exactly what went wrong and preserve the user
input. That's my definition of a site that reloads all the time.

- 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

SQLite is resilient but it's dangerous to use it with multiple threads
like how your go server does. You could use a single channel model to
write records one at a time but now you have a risk to lose data from
memory if your service restarts.

- 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.

That's true it can, but that means you need to deploy and configure one.

- 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.

You're absolutely right. None of it is "too hard". But the problem is
just how much time and effort are we willing to put into it. If the goal
is to make an open source polling platform that we can re-use in the
future, then absolutely all of this can be done. But if we treat this as
a one-off and see how it turns out, the scope seems exaggerated.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]