Once upon a time, at the dawn of the web, browsers and websites were simple ... Then slowly, step by step, more and more interactivity was added.
Does MongoDB still have an edge as a document-oriented database for JSON in particular? Or is Postgres better? Or at least good-enough to stick with it, since it is a more universal database, offering a richer feature set and wider applicability?
Data Consistency is simply a need to keep data consistent within a particular boundary and time. There are two main scopes ... Local data is immediately consistent - there are no delays, it appears either in its final form or not at all. In the global scope however, things look totally different.
In many systems, various actions can only be performed as some kind of Identity. We must authenticate ourselves by proving who we are. Authentication fundamentally is just an answer to this question: who are you and can you prove it is true?
Virtually every module - folder or versioned package in a modular monolith, separately deployed microservice - must own or at least read some data to provide its functionality. As we shall see, the degree to which module A needs data from module B is often the degree to which it depends on this module; functionality being another important dimension of dependence. This leads us to the following principles...
In many applications and systems, we must deal with concurrent, often conflicting and possibly lost, updates. This is exactly what the Concurrency Control problem is all about.
As we have recently analyzed how the Bitcoin P2P Network works, let's delve into arguably its most important software component - the Bitcoin Core, the reference client and the reference implementation of all aspects of the Bitcoin system. With the main goal of having a few questions answered...
Social media and various other online platforms require some sort of identity to provide their services and to customize experience to us. What does it mean exactly and how does it work in practice? Currently most, if not all, of these platforms - Twitter/X, YouTube, Reddit, LinkedIn, Facebook, Instagram, GitHub, Amazon, Spotify and the like - are account-based.
Events, and messages more broadly, are a battle-tested way of component to component, process to process, and/or application to application communication ... What if we were able to just use a type of SQL database already managed on our infrastructure to build a scalable Events Platform on top of it?
Peer-to-Peer (P2P) Networks introduce a completely new set of challenges. In the traditional Client-Server Architecture, there is a server and client ... Things work completely differently in the Peer-to-Peer (P2P) Networks. These networks consist of equal peers that communicate directly with each other. Their goal is to be as decentralized as possible and not to have any single point of control or failure.
To establish what these differences are, we will go through two implementations of Projects App - one as HTMX MPA and the other as React SPA. This makes our comparison more concrete and objective, since the same functionalities were implemented twice, only approach - MPA vs SPA - is what makes these cases different.
React and HTMX represent two completely different approaches to building web applications. React approach is JSON centric. It is driven by JSON, a data format that is totally different from what is needed to render web pages or their fragments - HTML ... HTMX approach is HTML centric. It is driven by HTML - data is received in the exactly same way it is required for rendering, there is no need for any transformations.
I love simplicity. Complexity is our eternal enemy and Simplicity is beautiful; rarely something is as simple as SQLite: a single-file, in-process database. It runs inside our application, there is no need for a separate database server.
Both databases solve the same problem: how to most effectively store and provide access to data, in an ACID-compliant way? ACID compliance might be implemented in various ways and SQL databases can vary quite substantially how they choose to go about it.
As we already know, HTMX pairs really nicely with Web Components. Shoelace is a popular and mature collection of configurable Web Components, which by definition are framework agnostic. Since writing our own components library is a ton of work, we should rather prefer using something ready and battle tested. Let's then see how this library plays with HTMX by building a real application!
There are hundreds and thousands of tools and frameworks out there, often solving the same problems or struggling to explain what the problem they are trying to solve is ... Because of this diversity and how powerful some of these tools are, it often feels like Magic. So many things possible, so fast and seemingly without a cost, without tradeoffs. But is it really the case?
We take the Internet, as it is, completely for granted. But have you ever wondered: what it is, how it works and who controls it? At its core, the Internet is just a...
When building landing pages and blogs, we usually want to have some traffic data and its analytics. Monitoring activity on our web pages turns out to be quite useful ... Similarly, when we build web applications, we want to have analytical data to understand the behaviors and interactions of our users.
Before talking about module communication, it is important to emphasize the consequences of chosen module design. Problems that we will face when communicating between modules, how often and how much of communication there will be, depend mostly on decided modules structure ... Assuming that we have modules that depend very little on each other, but sometimes they do need to talk with each other - how can they and when they should?
HTMX is a promising technology that simplifies many things when building web applications/systems ... That is great when it comes to local development and simple experiments, but what about Production?
Web
JSON
Performance
Database
Security
Backend
C++
Programming
AI
Python
Open Source
Web Development
HTML
Frontend
Tutorial