eandre

Unfortunately not – this is what building modern cloud based software is like! This software complexity crisis is what we're trying to fix with Encore [1], if you're interested.

[1] https://encore.dev

I've been working on something that might be interesting to you [1]. It gives you the full flexibility of a programming language while removing all the boilerplate surrounding your business logic through static analysis.

Have a look at the Encore Playground [2] to see a real-world example.

[1] https://encore.dev

[2] https://play.encore.dev/vHZHuXf2zca3dg

Thanks, that means a lot! Unlike other offerings the focus is really on the development experience, hence the focus on ease-of-use and simplicity as you say. The goal is to provide a best-in-class developer experience; the serverless part is really just a piece of that, if that makes sense?

Great article. Working on my own startup (https://encore.dev) I also feel the urge to measure my progress in terms of output, not outcomes. I have to constantly remind myself that what matters is the outcome. Focus on producing a concrete, visible artifact every day and use that as your measure of progress instead.

And make sure to stay sane; startups are not a balanced lifestyle but that just means we need to push ourselves harder to find balance, as opposed to pushing ourselves even further out of balance.

I can really recommend "How to Take Smart Notes" [1] by Sönke Ahrens. It's made a real difference for me. Ignore the self help-sounding title and give it a chance.

[1] https://www.goodreads.com/book/show/34507927

Wow, this looks great! Will check it out immediately tomorrow morning!

I think the confusion comes from that not everybody thinks of "passing data to the database layer" as an output, but only an input to the next layer. If you think of this input as an output from the previous layer, then your advice makes perfect sense. But I don't think everyone thinks that way so it might help to clarify what "output" means in this context.

That's a reasonable point. Maybe I should update the post to guard it with a mutex to discourage newcomers from doing something subtle. Thanks for the feedback!

I agree with the article and am facing the same challenges in my own startup: how much, and what, to open source?

It's a platform that offers a simpler way of building serverless backends [1], and so it's naturally targeting developers. As a developer myself I know how much I appreciate things being open-source and free. At the same time it would come with huge business model challenges in my case and kind of erode what my product is all about (simplicity and having things taken care of for you).

While the article does not really offer any answers, I'm curious if anyone else has any experience to offer in this regard?

[1] https://encore.dev

Good point, I didn't necessarily mean simpler primitives but rather "higher-order" primitives. We need to move to a higher level of abstraction on top of a new layer of primitives (even if those primitives themselves are more complex than the ones we have today).

This article is conflating the benefits of a particular way of doing implementation, and JWT as an implementation of that approach to authentication. That's dangerous because it n discourages people from thinking carefully about the semantics involved. Authentication is a topic where the trade-offs should be carefully evaluated for your particular situation.

I do agree that if you need the particular way of doing authentication that JWT is designed for, JWT is indeed a great implementation and can save you a lot of time.

I agree! But isn't that the beauty in abstractions? If you are using an unmaintained file system with a CVE, the beauty of the POSIX interface means you can just migrate to another file systems and basically all applications would just continue working. I'm not advocating for having nobody at the wheel to notice and address security vulnerabilities, just that those concerns should be isolated from the application code to a much greater extent than they are today.

I agree that the parts are needed and the complexity essential. What I mean is that we need higher-order primitives that abstract away and shield us from the conplexity. Just like we don't need to spend time crafting TCP packets by hand, I don't think we should have to mess with transport protocols, writing RPC calls by hand, juggling yaml files to stand up Kubernetes clusters, and so on.

I've been working on building something like this for a year now [1] and it's certainly quite different from how we do backend development normally,but that's also the point :). The tricky part is to find abstractions that are general and non-leaky so they can be leveraged to build a wide variety of software. Feedback appreciated!

[1] https://encore.dev

I used TailwindCSS which I can highly recommend, but the design and components were all custom made by myself :)

I share Nelson's belief that we can conquer the rampant complexity in modern software applications. I'm generally in favor of the approach he's advocating for -- working to understand the layers of the stack rather than treating them as a black box.

That said I can't help but feel that the problem is a missing abstraction. As computers and the internet grew we did a lot of experimentation, learned from it, and came up with abstractions to help us conquer higher-order complexity through chunking.

But for cloud-based software today, creating a "simple" (in terms of business logic) backend API requires an insane amount of moving parts and complexity to have it up and running, but there is no underlying abstraction that offloads this complexity from the engineer writing the business logic. It's as if the people writing business logic were hand-crafting IP packets, but instead of juggling bits we're juggling build pipeline definitions and Kubernetes yaml files.

We need higher-order primitives for writing software.

That was a quite interesting read; I hadn't heard that analogy before. It's a shame the formatting of the page really makes it difficult to engage with the content.

That's the Baader-Meinhof phenomenon talking [1] :)

[1] https://science.howstuffworks.com/life/inside-the-mind/human...

This is certainly true, but it strikes me that the solution must be a move towards simpler primitives so that managing a cloud-based piece of software doesn't require so many moving parts.

I really appreciate the approach of building something simple (in user experience but also in implementation). These days it's so easy to get sucked in and end up spending months setting up Kubernetes clusters and the "that won't scale"-type thinking.

Liste looks great! I've been looking around for a better tool to aid in note-taking after all the posts around this space over the last few weeks. Will keep an eye on it and good luck with the launch.

How did you decide to start a company around the idea before launch?

This is good advice. I've been working on a side project for almost a year now [1]. It's a constant struggle with the pressure to reach a certain amount of users or impact, when at the end of the day I've just been building it to scratch my own itch. This article is a helpful reminder of that.

[1] https://encore.dev

I believe this is what Roam[1] is kind of built for, whether they intended it or not. I haven't used it but was inspired to take another look at it after this article.

[1] https://roamresearch.com/