Chapter 3 notes. How to model services. What makes a good service: loose coupling high cohesion Loose coupling means a change to one service should not require a change in another service. Tight coupling might means “chatty” communication, or wrong integration style was chosen that binds services tightly. High cohesion — we want related behavior to be in the same service, and unrelated behavior to live in another service. Bounded context helps with those two aspects of a good service. Todo: to learn more about bounded context. ...

I like that book and decided to make a “short” version for myself to remember it better. The book is only 190 pages long but it has lots of valuable advices and author takes things straight to the point. This is just my own “retelling” of the book. If you are reading this I encourage you to first buy and read the whole book and only then this text below might make sense to you. Or not. ...

Designing Data-Intensive Applications by Martin Kleppmann is an amazing journey into the world of distributed systems. It is a must read, especially if you are like me — self-taught programmer. I think it will be usefull even if you do not plan to work with distributed systems, it is just interesting per se. I really learned a lot, than you Martin! I have a feeling that I managed to digest and remember around 5% of the information, and the book contains a lot of good stuff, I mean a lot. So for myself I decided to get table of book contents and augment it with little hints and notes that will be helpful in case I want to remember something quickly. ...

what is JOIN FETCH exactly? So it was not clear from the start and search engine results might confuse you even further. Here it goes — JOIN FETCH is not an SQL feature and it does not relate to FETCH keyword in t-sql or any other sql dialect that uses it. Note: hydration is the process of turning fetched rows from the database into object/entities. Embarrased to admit that I did not knew exactly what it is. ...

As I’m improving my data structures knowledge and understanding I’m trying to solve different puzzles. One of them is to detect cycle in a sigly-linked list. Singly-linked list consits of nodes that reference one another. A node could look like this: class Node: def __init__(self, value=None): self.next = None self.value = value So it has two properties — next that contains next element, and value that contains data. Could be more complex than this but lets not complicate. ...

Disclaimer: I might be wrong about variance. Buyer beware! Variance is a property of class hierarchies describing how the types of a type constructor affect subtypes. Type constructor is a thingy that builds new types from the old ones. In general, a type constructor can be: Invariant: if the type of the super-type constrain the type of the subtype. In plain english if you say you return an array in some method of your super class — all sub-classes must comply and return array as well. Covariant: if the ordering of types is preserved (types are ordered from more specific to more generic). You can imagine hierarchy tree and follow it from leaves to the root (top most superclass). Contravariant: if it reverses the order (types are ordered from more generic to more specific). Traversing type hierarchy from the root to the leaves. Here is an example of invariant return type in class hierarchy, note same return types: ...

I really like how Martin Kleppmann described ACID in his book, hence a little excerpt to remember. ACID stands for Atomicity, Consistency, Isolation, and Durability It was first coined by Andreas Reuter and Theo Härder in 1983 in attempt to describe all that is necessary for the database to be fault-tolerant as much as possible. Atomicity Database should support transaction, namely you should be able to group you request statemets and execute them at once. The very important feature here is abortability — ability to rollback any changes done in case we have an error in transaction somewhere along the way. ...

REST is paradigm or architectural style that defines your API. One of the most important and yet simple REST consept is resouce/endpoint, I really like resource term so I’m going to use it here. In REST paradigm URL is a resource, e.g. — http://example.org/test/foo. You should strive not to use verbs in URL. The only verbs you need are HTTP verbs — GET, HEAD, POST, PUT, PATCH, OPTIONS, TRACE. Subresource in REST looks like this — /posts/{id}/author. With GET verb it means — fetch me an author of this particular book. It makes no sense to continue a subresouce with additional nesting. If you have situation like this TRY to move that to separate endpoint. Although the correct answer is always — “it depends” : ) If you are developing something vast and complex e.g. github api than you can/should use longer URLs to fit in all the domain logic. ...

In Object-oriented programming we often need to persist object to the database for later retrieval. For that to work smart people invented Object-Relation Mapper that does object to db conversion and vise versa. Such ORM object are usually called entities and are passed around in application and are subject to CRUD operations. ORM implies existence of DBAL(Database Abstraction Layer) and Data Access Layer. DBAL abstracts Quering language details of different databases and supports many databases at once. Theoretically you can switch seamlessly from one database to another, though I never heard of practical execution of this feature. Active record and Data Mapper are Data Access Layer patterns or better to say paradigms. ORM advantages: ...

Proxy Design Pattern First, some definitions. Wikipedia: In computer programming, the proxy pattern is a software design pattern. A proxy, in its most general form, is a class functioning as an interface to something else Design Patterns. Elements of Reusable Object-Oriented Software: Provide a surrogate or placeholder for another object to control access to it. There are a few reasons to use Proxy pattern and control access to the underlying object: ...