I've been working on a project that largely addresses this need. It's a distillation of knowledge gained from building web apps of my own as well as for startups for the past several years. The stack comprises of React (via NextJS), GraphQL, Express, Node.js, and PostgreSQL - all written w/ TypeScript.
The goal was to provide a hardened boilerplate app with no distinct featureset but at a minimum have things like ORM, user authentication, migrations, as well as a frontend web UI set up so that it could be used as a head-start for any web app projects in the future.
It's built for fast developer experience, while decoupled enough (a la containers) so that it can easily be taken into a kubernetes cluster for scale. (Still a monolith though.)
The project is private now, but happy share it on request. Also happy to answer any questions.
This sounds right up my alley honestly, could you explain a bit more about the affordances you set up for the decoupled container component to allow it to grow from a few containers to an orchestrated K8s cluster? Just some insight into how and when one decides to grow from a container or two to full on clusters would be really good to know.
As for sharing, while it's very generous of you to offer access and I'm certainly interested in using it once it gets a public launch, I'm much more in pursuit of the thinking behind system design choices and better developing the intuition that makes those choices. Honestly the framework you're putting together sounds like it could help a lot of people with similar problems to me though :D
Sure; because it is a monolith, it makes things simpler by having just the one backend container to scale. So it's a matter of making more instances of it available (via # of pod replicas in your k8s cluster) for increasing availability.
You can start using k8s right away, and just have 3 replicas running to start. As you scale, just up the number of replicas (and nodes as you need them) as you go.
Your real bottleneck becomes the database at that point (in addition to any blocking 3rd party APIs you may be using), which I would not host in k8s but use a managed service such as AWS RDS. This bottleneck will make itself apparent later on, depending on your application and the scale you reach. But you should definitely have the resources to cross that bridge once you, if ever, reach it, because you should be dealing with a large number of customers at that point.
Ah gotcha yeah at the small scale(?) scaling we're talking about monolithic applications, being a bit simpler to organize and run, do still make for a compelling solution. That's a great tip regarding how to handle ballooning storage issues via managed cloud offerings (in the weird case I make something that really works) that I hadn't considered. However, it's starting to feel like these scaling questions/solutions are a lot more akin to Factorio bottleneck chasing than I would like haha.
> Years later I ran into Phil at the symphony. I asked him I how he was able to come up with such a great script. He blushed and said he had worked on it for nine years. I know spending a long time writing something doesn’t guarantee success. But not giving up on a good idea almost always does.
I experienced a similar transition, albeit this was over 10 years ago. I've come to realize that a balance between both meatspace and hyperspace ends up being most satisfying. For me, the former was very valuable in introducing new experiences (learning and playing music, construction projects, hobbies like hiking and surfing), but the lack of cognitive and 'online' stimulation will make itself apparent over time.
Prioritizing important work (whether its learning or executing on tasks) for the morning right after waking up
Healthy sleeping and eating habits
There are a plethora of tools out there to optimize your workflow, but I think that is more a matter of preference.
Videos can be hit or miss. The right videos can jam pack a ton of information and get you learning complex topics very quickly. Books and articles have their place too, though I tend to read later in the day into the evening when I'm more keen to winding down.
One common thing I tend to do: I may end my day working on something that leads me to a new pillar of information or complicated topic that I need to grok. In those situations, I stop the day there, and plan to wake up the next morning to research the topic (over coffee), and absorb any videos, articles, material I can get my hands on. Your brain can do amazing things with a little bit of caffeine and deep focus after a good night's sleep.
Realizing that one forgets the majority of what they learn day-to-day is a harrowing realization. It was for me, at least.
I built this simple web app to help me keep track of what I learn, and later opened it up to the general public. I've gotten good feedback so far - interested to hear more: https://wyl.today
I've thrown in a screenshot on the landing page to help better inform what the user is getting into. that's all I can do for now given my time constraints. later, I'd like to flesh out a decent landing page.
Alternate theory is that the sociohopaths (diagnosis not epithet) have won.
The values people can be browbeaten, outnumbered and marginalized. Once that happens it’s hard to change back, even if you identify and remove the ringleaders.
According to the first graph, it's $30,000 in total sales over the last 2 years which forced him to continue freelancing as his main income. This post is basically announcing ramen profitability. (Of course it's still a great achievement to turn any profit on a side project, let alone supplant his main income)
While you're right that $30K isn't hugely profitable, his growth curve looks good, especially at the very end. He could probably either reduce his focus and cash $1300 in profit extra a month or continue and it appears that his product could keep trending up for a while. That's a really sweet position to be in IMHO
I have been in the market for a new term, for what to say to people what my goal is with my side projects. Up until now I have been saying, it's not making much, it's all supposed to be for some "beer money"...
Welp. I stopped drinking.
Now I can call it ramen money instead. Cool!
(I do dropshipping of computer hardware, specializing in computerchips). And currently building an OS-disk to the enthusiast-market for Apple G5 workstations (yes, it's a hyper niche, and will only cover my ramens) :)
I wouldn't call it "necessary" at all. Some of it is useful shorthand and steals some credibility for you if you're dealing with people who are way too deep in startupland, but most of the advice I've ever read from Paul Graham is on the more basic end of things.
If you have some basic notion of running a business, you probably won't find much in the way of revelations there. (Some of this is the "Seinfeld is Unfunny" effect, because the better advice you'll find in his blog is now common knowledge, but more is that running a tech business is still running a business.) If you aren't familiar with running a business I can see it being a useful naming-of-parts exercise, though.
Intresting that SNES is missing from the nintendo list. There's a good bit of literature on the underlying implementation for SNES roms: https://github.com/bttf/snes_dev
(Full disclosure: I spent a little time accumulating aforementioned literature)
The goal was to provide a hardened boilerplate app with no distinct featureset but at a minimum have things like ORM, user authentication, migrations, as well as a frontend web UI set up so that it could be used as a head-start for any web app projects in the future.
It's built for fast developer experience, while decoupled enough (a la containers) so that it can easily be taken into a kubernetes cluster for scale. (Still a monolith though.)
The project is private now, but happy share it on request. Also happy to answer any questions.