fpereiro

8 ms·

31.
Ask HN: Acceptable CSRF Token Lifecycle?
1 points by fpereiro 7y ago|0 comments
32.
by fpereiro 7y ago
It looks like Lua is the main scripting language; which is a fine choice by me; the few times I worked on redis transaction scripting in Lua (since Lua is the language for doing that) the experience was very pleasant. Are you building a pro
33.
by fpereiro 7y ago
I stand corrected, you're right! I hadn't heard about OpenResty. It's amazing that this exists, I would have never thought it possible (because of what I saw as inherent limits in what can be expressed in terms of nginx confi
34.
by fpereiro 7y ago
I added recently a bit more of detail in the document explaining when I would use redis (and when I wouldn't) to build production systems, here: https://github.com/fpereiro/backendlore#redis . For most application
35.
by fpereiro 7y ago
Before your comment I didn't know about the existence of KeyDB, but now I do - thank you for that! My main issue with scaling Redis is not performance or throughput, but doing it in a controlled, understandable manner which maintains c
36.
by fpereiro 7y ago
I don't think it is at all possible to use nginx to write application logic otherwise than serving static files and perhaps doing some URL transformations. node gives you a full programming language that's necessary for implementi
37.
by fpereiro 7y ago
That's a good question. I'm going to try first with Hetzner and measure latencies from different places; if this becomes an issue, I'll definitely consider complementing the infrastructure from elsewhere. But I'd rather
38.
by fpereiro 7y ago
I've never really tried, but it looks like lists and hashes could be implemented in Postgres through json blobs. That would still leave out sets and zsets, which I also find essential in most work I do with Redis. Besides having all th
39.
by fpereiro 7y ago
This is not an easy question to answer, but in my experience it pays off to ponder it carefully. So far, the heuristic that seems to work better for me is to keep the overall surface of the app small and try to keep everything in a single a
40.
by fpereiro 7y ago
Using websockets for a collaborative app makes all the sense in the world (incidentally, I realize I've never written one an app of that kind). My pleasure! Being part of this thread has been an amazing learning experience.
41.
by fpereiro 7y ago
Redis gives you fundamental data structures (lists, sets, hashes - plus a few other like zsets and hyperloglogs) that represent a powerful way of expressing computation. I'm not acquainted with the full spectrum of Postgres' data
42.
by fpereiro 7y ago
Glad you find them interesting! As for a redis-like disk-first database, it would be amazing, but I don't know if it is really possible (unless performance was severely sacrificed). This could be an interesting area to explore.
43.
by fpereiro 7y ago
I think it does have to have a certain elegance (or better, conceptual integrity), otherwise it won't be able to provide a flexible and understandable interface for handling all the various use cases.
44.
by fpereiro 7y ago
Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be p
45.
by fpereiro 7y ago
I'm curious as to the advantages of using Debian over Ubuntu on the server - is it considered generally more stable or better debugged? This is something I've never explored and am interested in your thoughts about it. At some poi
46.
by fpereiro 7y ago
I also rambled further here: http://federicopereiro.com/why-es5 .
47.
by fpereiro 7y ago
The only alternative would be to create an elegant system that is also in itself an open standard. I don't see a way around this double requirement. It sounds like something mighty interesting to work in.
48.
by fpereiro 7y ago
Hi there! - I choose js/node as my server-side language of choice. This is because I love both js the language and node itself, and so far haven't seen the need to try something else. That doesn't mean, however, that it shoul
49.
by fpereiro 7y ago
I love working with fundamental data structures (sets, lists, hashes) much more than working with relational databases. I feel I'm more productive and my code is shorter. It does, however, require far stricter validations in the code;
50.
by fpereiro 7y ago
I normally don't work with websockets, just JSON, but perhaps that's because all the applications I work on are basically glorified CRUDs. If your application is essentially a CRUD, however, JSON might be more than enough. I'
51.
by fpereiro 7y ago
At some point I'll do a public writeup of my planned cost structure. Hetzner's EX62 servers ( https://www.hetzner.com/dedicated-rootserver ) are about 10 USD/mo/TB of disk and it would be hard to go over t
52.
by fpereiro 7y ago
> One second is a significant gap for data loss. Definitely agree. I would not, for example, create a financial transaction system that is not backed by an ACID database that persists to disk. If you have time/interest, I'd lov
53.
by fpereiro 7y ago
Good point. I'm drawn to redis not so much for its performance (which can be comparable to that of a relational database) - but rather for the expressive power of storing data in general purpose data structures (hashes, lists, sets) ra
54.
by fpereiro 7y ago
I added a few more notes on when/why to use Redis and when to use something else: https://github.com/fpereiro/backendlore#redis . Redis can take you surprisingly far as a general purpose database. I prefer to use
55.
by fpereiro 7y ago
Please see https://github.com/fpereiro/backendlore/issues/5 .
56.
by fpereiro 7y ago
I believe that npm no longer allows for republishing existing versions. Wouldn't this restriction remove this vulnerability altogether?
57.
by fpereiro 7y ago
I am consdering to move "ulogs" out of redis and into files because of the potential memory usage - perhaps a hybrid approach where only new logs are in redis would work best. I don't have a definitive solution yet. However,
58.
by fpereiro 7y ago
Glad to hear! Part of the reason I put all of this out there is to offer a different point of view that has worked for me and others I've worked with, and to stimulate debate and fact-based (or at least experience-based) interactions r
59.
by fpereiro 7y ago
Definitely a tradeoff - I'm biased towards working in teams of only 2-3 people. Larger teams would probably benefit much more from more structure and process.
60.
by fpereiro 7y ago
> why is all of this still needed ? That's the million dollar question! It also vexes me that all of this is necessary. I hope like crazy that there will be a radically better approach in 5-10 years. I am not aware of solutions that

More ›