
Show HN: A Go web server with logging, tracing, and demo apps in a single file - photon_lines
https://github.com/photonlines/Go-Web-Server
======
erikig
I'm enjoying these "in a single file" projects. They aren't often the paragon
of best-practices but they make it easy for newbies to peep in on the syntax
and see how complex problems can be solved. They are also usually a lot easier
to try out, compile and deploy.

Here are a few others:

\- Twitter Clone in Haskell in a single file -
[https://news.ycombinator.com/item?id=21616661](https://news.ycombinator.com/item?id=21616661)

\- MPEG1 in a single C file -
[https://news.ycombinator.com/item?id=20643336](https://news.ycombinator.com/item?id=20643336)

\- SingleFile CMS -
[https://news.ycombinator.com/item?id=18336986](https://news.ycombinator.com/item?id=18336986)

~~~
everdev
It is an interesting idea, but it can be overkill. Just because it can be done
doesn't mean it should be.

For example, there are ~130 lines of CSS in the Go file. Most editors have
auto-formatting and suggestions for CSS for files ending in .css, which you
won't get with this setup.

Also, with 885 lines of code, you have to wonder if reading the code is easier
via scrolling / searching a single file or via tabs with multiple files.

------
laurent123456
> all in a single file

It's not really an advantage, is it? Having everything mixed up into one giant
file just makes the code much harder to make sense of.

~~~
save_ferris
I recently started learning go and I've been struggling with the lack of
modularity across smaller codebases like this. For all of the great tooling
around formatting go, I'm kinda surprised by some of the code organization
decisions I see.

~~~
jerf
There's some differences in style. I take a very aggressive stance on
separating my modules; my thought is that it's relatively easy to understand
what any given module is doing if it is small and focused and clearly pulls in
its dependencies. But it's a non-trivial challenge to keep it all so nicely
isolated and avoid loops. Worth it, I think, or I wouldn't do it, but non-
trivial. There are also a lot of people who pretty much just punt and put
everything in one module, so they don't have to deal with circular issues. I'm
not sure I see a clear community consensus.

------
SamWhited
Might be worth structuring this like a normal Go project (eg. right now this
is in a package called "src", which is not great) if it's meant for education.
Also the listen address is actually a port, not an address. Might be worth
making that a generic address so the user can specify an interface to listen
on.

~~~
tikkabhuna
Having looked at writing a simple Go web service recently. I spent far more
time than I'd like looking for good examples of how to structure it.
Especially when many examples don't use Go Modules.

------
throwaway894345
This is really cool! One suggestion: logging to a file makes it harder for
things like Docker to exfiltrate logs. Log to stderr by default, and the
caller can redirect to a file on disk if they want to.

~~~
majormjr
Why log to stderr instead of just stdout?

~~~
ktm5j
Maybe just convention? It's standard practice to use stdout for directly
interacting with a user and stderr for log/error type messages. You can
redirect stderr to a file to get all of your log messages, but keep stdout
available for interacting with the user. Super useful to separate meta-
messages out in this manner.

Here's a good blog post with more info on stderr for those interested:
[https://www.jstorimer.com/blogs/workingwithcode/7766119-when...](https://www.jstorimer.com/blogs/workingwithcode/7766119-when-
to-use-stderr-instead-of-stdout)

~~~
anderspitman
Might be because stdout is buffered, so you don't always get output right
away, while stderr is unbuffered.

------
sagichmal
No reason to use a global int32 as a healthiness bit. Treat it as a dependency
to the health middleware and the signal handler.

------
Pelican
If "in a single file" means having your html and your javascript in your go
file, that's not a feature...

~~~
photon_lines
I agree! The purpose of this was teaching, and not necessarily following all
of the best practices! I made raw files which contain the go HTML templates,
as well as the JS and CSS files available within the repository in case anyone
wanted to reference these instead of including the raw code within main.go!!

------
zubairq
How do I see the HTML and css in the GO code? Is it inlined somewhere ?

------
aaronmgdr
ok but its over 800 lines. I guess that's small for everything it does? Yet
it's certainly more than the size I think when i hear "single file"

