| I have a hard time pinning down why it's so hard to read. I think it's because some of your sentences aren't actually full sentences. Examples: "But often, especially with nascent projects, we can’t afford." "From full backend-as-a-service solutions like Firebase, to tools like ORMs to abstract and simplify dealing with databases." "Simple, with an architecture that already internalizes all of the common issues seen when handling events." You also sometime use sentences that are too verbose or hard to parse. Example: A) "In this post we’ll show how the lack of good abstractions leads to build-your-own backends lacking a key component that is present in most modern backends: a message queue." B) "In this post we’ll explain why message queues are important to a good back-end, and why developers may overlook them. (part that doesn't need to be said: because of the focus on database-centric abstractions.)" A) "If you ask most people, a backend is comprised of a database where the data can be stored, a business logic layer to mediate access to that data, and a couple of authentication components. But if you ask modern backend engineers, the answer differs. Yes, you have all that, but there’s a major component missing in this picture: a message queue. From modern alternatives like Redpanda, to established systems like Kafka, message queues are an integral part of most professional backends in use today." B) "Most modern back-end engineers will attest that a message queue, such as Kafka or RedPanda, is crucial to a good back-end." Generally I'd get rid of the conversational, quirky tone, I think it'll improve things stylistically. For the content itself I'd write a clearer plan with titles and subtitles, and the idea you want to convey in each paragraph. Also a good tip is to always write the introduction at the end, it makes it clearer in your mind what you're actually trying to convey. |