fix(blog-announce): typos

Signed-off-by: Alex C-G <alexcg@outlook.com>

Author: alexcg1

blog/01-announcement.md

@@ -1,12 +1,11 @@
-
 # DocArray v2: What and Why
 
 DocArray has had a good run so far: Since being spun out of Jina ten months ago, the project has seen 141 releases, integrated six external storage backends, attracted contributors from five companies, and collected 1.4k GitHub stars.
 
-And yet we feel like we have to bring some big changes to the library in order to make it what we want it to be: the go-to solution for modelling, sending, and storing mulit-modal data, with a particular soft spot for ML and neural search applications.
+And yet we feel like we have to bring some big changes to the library in order to make it what we want it to be: the go-to solution for modelling, sending, and storing multi-modal data, with a particular soft spot for ML and neural search applications.
 
 The purpose of this post is to outline the technical reasons for this transition, from the perspective of us, the maintainers.
-You might als be interested in a slightly different persepective, the one of Han Xiao, CEO of Jina AI and originator of DocArray. You can find his blog post [here](https://jina.ai/news/donate-docarray-lf-for-inclusive-standard-multimodal-data-model/).
+You might also be interested in a slightly different perspective, the one of Han Xiao, CEO of Jina AI and originator of DocArray. You can find his blog post [here](https://jina.ai/news/donate-docarray-lf-for-inclusive-standard-multimodal-data-model/).
 
 If you are interested in the progress of the rewrite itself, you can follow along on our [public roadmap](https://github.com/docarray/docarray/issues/780).
 
@@ -90,7 +89,7 @@ from docarray import DocumentArray
 da = DocumentArray([MyDoc(txt='hi there!' for _ in range(10)])
 ```
 
-However, the commiment to a dataclass-like interface allows for DocumentArrays that are typed by a specific schema:
+However, the commitment to a dataclass-like interface allows for DocumentArrays that are typed by a specific schema:
 
 ```python
 da = DocumentArray[MyDoc]([MyDoc(txt='hi there!' for _ in range(10)])
@@ -188,24 +187,24 @@ This offers a lot of convenience for simple use cases, but the conflation of the
 - It is not always clear what data is on disk, and what data is in memory
 - Not all in-place operations on a DocumentArray are automatically reflected in the associated DB, while others are. This is due to the fact that some operations load data into memory before the manipulation happens, and means that a deep understanding of DocArray is necessary to know what is going on
 - Supporting list-like operations on a DB-like object carries overhead with little benefit
-- It is difficutl to expose all the power and flexibility of various vector DBs throught the `DocumentArray` API
+- It is difficult to expose all the power and flexibility of various vector DBs through the `DocumentArray` API
 
-All of the problems above currently make it difficult to use bector DBs through DocArray in production.
-Disentangling the concepts of `DocumentArray` and `DocumentStore` will give more transparancy to the user, and more flexibility to the contributors, while directly solving most of the above.
+All of the problems above currently make it difficult to use vector DBs through DocArray in production.
+Disentangling the concepts of `DocumentArray` and `DocumentStore` will give more transparency to the user, and more flexibility to the contributors, while directly solving most of the above.
 
 ## The Why: Web Application Perspective
 
 Currently it is possible to use DocArray in combination with FastAPI and other web frameworks, as it already provides a translation to Pydantic.
 However, this integration is not without friction:
 
 - Since currently every Document follows the same schema, as Document payload cannot be customized
-- This means that one is forced to create payload with (potentially many) empy and unused fields
+- This means that one is forced to create payload with (potentially many) empty and unused fields
 - While at the same time, there is no natural way to add new fields
 - Sending requests from programming languages other than Python requires the user to recreated the Document's structure, needlessly
 
 By switching to a dataclass-first approach with Pydantic as a fundamental building block, we are able to ease all of these pains:
 
-- Fiels are completely customizable
+- Fields are completely customizable
 - Every `Document` is also a Pydantic model, enabling amazing support for FastAPI and other tools
 - Creating payloads from other programming languages is as easy as creating a dictionary with the same fields as the dataclass - same workflow as with normal Pydantic
 
@@ -219,7 +218,7 @@ With this in mind, DocArray v2 can offer the following improvements
 - It is no longer needed to re-create the predefined Document structure in your Protobuf definitions
 - For every microservice, the Document schema can function as requirement or contract about the input and output data of that particular microservice
 
-Currently, a DocArray-based microservice architecture will usally rely on `Document` being the unified input and output for all microservices. So there might be concern here: Won't this new, more flexible structure create a huge mess where microservices cannot rely on anything?
+Currently, a DocArray-based microservice architecture will usually rely on `Document` being the unified input and output for all microservices. So there might be concern here: Won't this new, more flexible structure create a huge mess where microservices cannot rely on anything?
 We argue the opposite! In complex real-life settings, it is often the case that input and output Documents heavily rely on the `.chunks` field to represent nested data. Therefore, it is already unclear what exact data model can be expected.
 The shift to a dataclass-first approach allows you to make all of these (nested) data models explicit instead of implicit, leading to _more_ interoperability between microservices, not less.