You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,13 +71,13 @@ Servers need to include converters between all versions.
71
71
72
72
Clients only need to inlucde a single version of the schema since the server is responsible for version conversion no matter what version you connect with.
73
73
74
-
**Embedded vs Negotiated Versions**
74
+
**Embedded vs Pre-Negotiated Versions**
75
75
76
76
Every message has a version associated with it. This version is either:
77
77
78
-
-Pre-negotiated (via mechanisms like HTTP request query parameters or handshakes)
79
-
- For example, you can extract the version from a request like `POST /v3/users`
80
-
- Embedded in the message itself in the first 2 bytes of the message (see below)
78
+
-**Embedded** in the message itself in the first 2 bytes of the message (see below)
79
+
-**Pre-negotiated** via mechanisms like HTTP request query parameters or handshakes
80
+
- For example, you can extract the version from a request like `POST /v3/users` as `v3`
81
81
82
82
**Embedded Binary Format**
83
83
@@ -96,10 +96,10 @@ The layout looks like this:
96
96
97
97
The core of why VBARE was designed this way is:
98
98
99
-
- Manual evolutions simplify application logic by putting all complex evolutions & defaults in a conversion code instead of inside your core applciation logic
100
-
- Manual evolution forces you to handle edge cases of migrations & breaking changes at the cost of more verbose migration code
101
-
- Stop making big breaking v1 to v2 changes — instead, make much smaller schema changes with more flexibility
102
-
- Schema evolution frequently requires more than just renaming properties (like Protobuf, Flatbuffers, Cap'n'proto) — more complicated reshaping & fetching data from remote sources is commonly needed
99
+
- Manual evolutions **simplifies application logic** by putting all complex evolutions & defaults in a conversion code instead of inside your core application logic
100
+
- Manual evolution **forces developers to handle edge cases** of migrations & breaking changes at the cost of more verbose migration code
101
+
- Stop making big breaking v1 to v2 changes — instead, **make much smaller schema changes** with more flexibility
102
+
- Schema evolution frequently requires more than just renaming properties (like Protobuf, Flatbuffers, Cap'n'proto) — **more complicated reshaping & fetching data** from remote sources is commonly needed
0 commit comments