Live data from Hacker News

Show HN: Orange Forum – Web 1.0 style forum written in Go

goodoldweb.com

81–90 of 178 posts

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#81
post #71

Earlier quoted context omitted.

SQLite is ok if you don't have much traffic (for example personal blogs), but you can't replace a db like Postgresql with SQLite if you have lot of concurrent traffic.

99% of the internet can use SQLite. Not just "personal blogs". Just about anything that's not facebook/twitter/google. I think you underestimate how much load it can handle.

Supposing that your server-side tech uses multiple workers to render pages, I suppose you have to serialize the access to the SQLite file. What is the best way to do this?

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#82
post #81
post #71

Earlier quoted context omitted.

99% of the internet can use SQLite. Not just "personal blogs". Just about anything that's not facebook/twitter/google. I think you underestimate how much load it can handle.

Supposing that your server-side tech uses multiple workers to render pages, I suppose you have to serialize the access to the SQLite file. What is the best way to do this?

SQLite can handle concurrent reads, but needs to lock the entire DB when writing. Multiple workers shouldn't be a problem per se, but if you need multiple workers to support the traffic, then maybe a client-server db like postgres is a better choice.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#83

Earlier quoted context omitted.

Images are supported, but it's disabled in the live demo.

Good plan for your own sanity. Is there a way to disable the signup and just load users?

Signup can be disabled. Loading users will need some SQL.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#84
post #68

Earlier quoted context omitted.

> Like getting notified when someone @mentions or replies to you Really? _that_ is complicated? Serious question, do you find it complicated because you're still a beginner, or is there something I'm missing? What language(s) did you use?

A good example of "the devil's in the details" is the decision chart of how Slack decides whether to send a notification for a particular message. I mean, how complicated could it be, if the user is in the channel and he doesn't have notifications turned off, then send it, it's just a simple nested if statement, right? But, it turns out that when you map out all of the decision points, it's quite a bit more complicat…

Nice but misleading graph.

If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case.

Can probably be implemented in a regular function with about 30 lines of code?

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#85
post #41

I think you guys are awesome. Keep up good work. Battery, CPU and RAM of my laptop are having the same feeling. Can I deploy it as fcgi script on cheap shared Apache hosting?

Thanks! FastCGI is currently not supported. If your shared hosting allows you to run a binary that accepts connections on some port, it should work with Apache as a reverse proxy. I'll add fast cgi soon. It should be easy enough since golang's net/http supports it.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#86
post #81

Earlier quoted context omitted.

Supposing that your server-side tech uses multiple workers to render pages, I suppose you have to serialize the access to the SQLite file. What is the best way to do this?

SQLite can handle concurrent reads, but needs to lock the entire DB when writing. Multiple workers shouldn't be a problem per se, but if you need multiple workers to support the traffic, then maybe a client-server db like postgres is a better choice.

Writing does not lock readers if you use the WAL feature (Write-Ahead Log, introduced in 2010)

https://sqlite.org/wal.html

> WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#87

in the demo when a response is massive it takes a long time to load. example: https://groups.goodoldweb.com/topics?id=33 It needs to limit entries to a certain number of characters where you can click a "see all" button to see the rest of the long entry.

I missed limiting the size of user inputs. Will fix it soon.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#88
post #68

Earlier quoted context omitted.

> Like getting notified when someone @mentions or replies to you Really? _that_ is complicated? Serious question, do you find it complicated because you're still a beginner, or is there something I'm missing? What language(s) did you use?

Well this @mention is a bit more complicated than what one might think. For example: If someone creates a post, without any @mention, then edits it, and adds a @mention — then, do you detect this, when looking at the edits, and send a @mention notification now? And what if s/he edits the post again, and removes the @mention, then, do you remove the notification? Cancel the email if it hasn't been sent yet? And if the…

Sure, but the complexity you're describing is basically business logic. Incorporating it still shouldn't lead to a slow bloated web application.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#89
post #64

The irony is that because of the lean structure behind the server, this forum actually responds faster than most webfora that do use AJAX/SPA. Funny given that the whole purpose of AJAX/SPA was to reduce response time. That's it's reason for existing. Turns out it just complicates things ...

When you say "irony", are you genuinely surprised by this?

No, but I've seen comments on here from people under the impression that rendering on the client is a more efficient use of CPU, or that rendering a page in HTML is significantly more resource intensive than rendering the data in json. There is a generation out there that doesn't seem to know that server side rendering exists.

Re: Show HN: Orange Forum – Web 1.0 style forum written in Go

#90
post #84

Earlier quoted context omitted.

A good example of "the devil's in the details" is the decision chart of how Slack decides whether to send a notification for a particular message. I mean, how complicated could it be, if the user is in the channel and he doesn't have notifications turned off, then send it, it's just a simple nested if statement, right? But, it turns out that when you map out all of the decision points, it's quite a bit more complicat…

Nice but misleading graph. If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case. Can probably be implemented in a regular function with about 30 lines of code?

It's not hard to implement the logic when you have the rules. It's hard to define the rules.
Post reply on HN