Status Quo of Newsletterify

So it’s been a while since my last update and a lot has happened. I launched 2markdown) over the course of a weekend. digital office has taken most of my time while we’ve crunched the last two months. I didn’t have the necessary time to work on newsletterify I’m afraid. I still believe the idea is great and I’m still convinced that it’s worth a shot.

Let’s address some technical decisions that have become stumbling blocks for me. In terms of the tech stack for newsletterify, I initially opted for Golang, Gin, and GraphQL via gqlgen for the backend, along with TypeScript and SvelteKit for the frontend. However, a few unforeseen issues have surfaced:

• pagination really really sucks with graphQL and I really don’t need it. While it’s doable, it’s not trivial.
• I don’t need a graphQL API at all. I don’t need an API at all (for now).
• SvelteKit is complex and slow (at least for me)
• the login via ory kratos is expensive (no usable free tier) and hinders me from letting it sit unused for a while

The only downside? I have to deploy another redis instance as a session storage. The upside? I host with fly.io, so maintenance, costs, and deployment are trivial.

I built 2markdown with htmx and alpine.js and I’ve just been amazed by the simplicity and performance. And yes, I’ve come full circle. Back to the roots. I do think graphQL is great, frontend and backend for frontend is a great pattern etc. etc. Just not for newsletterify.

These decisions are technical and will be undone. The next steps are:

• move from ory kratos to custom-build auth via email links (just like 2markdown)
• move from graphQL and SvelteKit to htmx and alpine.js
• move from gin to fiber (I just like fiber more and can actually reuse a lot of code from 2markdown)

On top of these issues I have one major issue: memory. For my account the backend crashes when I try to edit a digest just because I have so much nice newsletters. That was the reason to start implementing pagination in graphQL. This is a tad easier to implement via htmx but still a big problem.

While these issues are of a technical nature, I also miscalculated on the pricing a bit. There were exactly two users: a friend of mine and me. Why? Because it’s hard to understand the value proposition and you couldn’t just log in and have a look. That’s why I’ll introduce a free tier (which is rather involved) of one digest.

For what it’s worth, the reasoning was cost-driven. You wouldn’t think so, but I pay by the number of processed emails. So even a free user with only one digest may cause high costs. I’m not sure if I can keep that up, but I’ll try.

However, I’m glad I built this project in a hexagonal architecture using DDD. That means I just have to rip out the frontend. Still, a lot of work, but it’s doable. So I’m very happy about that. I’m also still very happy with using golang.

Onward and upward!