What language is this? I visited https://www.phoenixframework.org/ and even watched a few minutes of a video but there's no mention of the programming language. I suppose the language is called Phoenix?
Elixir (on top if Erlang VM)
Show HN: Textdb.dev – simple data sharing for fun projects
31–40 of 79 posts
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#32What language is this? I visited https://www.phoenixframework.org/ and even watched a few minutes of a video but there's no mention of the programming language. I suppose the language is called Phoenix?
It's Elixir.
huh. I would have thought https://www.phoenixframework.org/ would mention Elixir then.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#33Re: Show HN: Textdb.dev – simple data sharing for fun projects
#34Very cool! Do you have any sort of dashboard displaying stats for the service? Simple totals would be interesting, of course (size, # of buckets, # of edits, etc.), but I'd find histograms of edits etc. per bucket particularly fascinating.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#35Is there an upper limit to the amount of data that can be stored on an endpoint?
There currently isn't, but it is intended for small amounts of data. Today or tomorrow I'll probably put a cap at 500Kb or so, which is still a heckload of data.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#36Earlier quoted context omitted.
That's pretty cool! Are you doing anything like rate-limiting to prevent abuse?
Thanks 8), rate limiting is just the most basic of nginx configs to like, 10 requests / second / ip
Really simple cool! One minor thing on the IP rate limiting side.... LOTS of mobile/cell users might end up NAT'ed behind a single IP. Just an FYI.
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#37Earlier quoted context omitted.
That's a cool idea, I'd definitely like to add the ability to create a little store with more safety, and that totally works with the goal of simplicity. I'll give it a shot.
It's a cool idea, but the old anti-pattern about security through obscurity applies.
I never really understood this argument, obscurity add an obvious layer of protection, not impenetrable of course, but still valid. Why is this different than an API key for example?
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#38I really like simple tools like this. Well done; I can see lots of uses for this, especially with the Serverless/Jamstack surge.
I love the idea of Hashing and read/write keys mentioned in this comment: https://news.ycombinator.com/user?id=miki123211
I also like the idea of batch requests so you can pul multiple keys at once, or set multiple keys at once. It seems better for everyone.
My only concern is that a small portion of users will undoubtedly try to abuse this with high volumes or large objects, or both.
Have you published any limits on value key size, value size, read/write limits for keys etc? It might be worth thinking about now before you have to shutdown users or shutdown the service due to cost.
Congrats again!
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#39Cool idea, nice implementation. But man, fix your README.md!
Re: Show HN: Textdb.dev – simple data sharing for fun projects
#40Earlier quoted context omitted.
It's a cool idea, but the old anti-pattern about security through obscurity applies.
I never really understood this argument, obscurity add an obvious layer of protection, not impenetrable of course, but still valid. Why is this different than an API key for example?
Security through obscurity refers to relying upon keeping the details of the security mechanism secret. An API key itself is a secret, but the mechanism for how that key is generated and used is public knowledge.
In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.