corrected spelling mistakes and made pdf

report/main.tex

@@ -22,28 +22,28 @@ Complex applications often require multiple programs to communicate with each ot
 
 An early and still possible solution for this type of problem is the SOAP protocol, which allows the processes of a web service to exchange XML data. Many modern applications, however, utilize different technologies due to several inconveniences like troubling scalability and noticeable message overhead.
 
-After its introduction \cite{fielding2000architectural}, REST, which is not a protocol like SOAP but a set of architectural principles, managed to gain outstanding popularity. Nowadays it is used by professionals and hobbyists alike and can be found at the core of many websites - from small projects up to Social Media platforms with billion users.
+After its introduction \cite{fielding2000architectural}, REST, which is not a protocol like SOAP but a set of architectural principles, managed to gain outstanding popularity. Nowadays it is used by professionals and hobbyists alike and can be found at the core of many websites - from small projects to Social Media platforms with billion users.
 
-But as it is often the case, there is no one-size-fits-all solution and developers may opt for an alternative to REST that better suits their needs. In this report, we present code examples for tRPC and gRPC, two technologies that differ from the well-known REST approach.
+But as is often the case, there is no one-size-fits-all solution and developers may opt for an alternative to REST that better suits their needs. In this report, we present code examples for tRPC and gRPC, two technologies that differ from the well-known REST approach.
 
 \section{Project description and outline}
 
-To learn about REST alternatives, we built a to-do App that runs in the Browser. The website allows users to create, edit and delete to-dos. Moreover, users can add images to make it easier to distinguish between existing to-dos.
+To learn about REST alternatives, we built a to-do App that runs on the Browser. The website allows users to create, edit, and delete to-dos. Moreover, users can add images to make it easier to distinguish between existing to-dos.
 
-The website uses tRPC for communication between frontend and backend. The backend stores the data regarding the created tasks while the frontend is responsible for presenting the data in an intuitive UI. Additionally, the backend sends requests to a service written in Rust, which is used to resize and compress the images. Aforementioned requests make use of gRPC.
+The website uses tRPC for communication between the frontend and backend. The backend stores the data regarding the created tasks while the frontend is responsible for presenting the data in an intuitive UI. Additionally, the backend sends requests to a service written in Rust, which is used to resize and compress the images. The aforementioned requests make use of gRPC.
 
 In the following, we present tRPC and gRPC code examples from the project to illustrate basic functionality from both frameworks. As a conclusion, we compare tRPC and gRPC to each other and to the REST approach.
 
 \pagebreak
 \section{TRPC}
 
-People use tRPC for full stack development. Many advantages come from having the same programming language, TypeScript, in the frontend and the backend. Developers do not have to learn multiple languages and knowledge obtained while implementing features on the client side may come in handy when improving the server side.
+People use tRPC for full-stack development. Many advantages come from having the same programming language, TypeScript, in the frontend and the backend. Developers do not have to learn multiple languages and the knowledge obtained while implementing features on the client side may come in handy when improving the server side.
 
 We built a to-do list App with tRPC, but it may be used to create any other type of website as well.
 
 \subsection{The code}
 
-Calling backend functions from the frontend is pretty straight forward. In contrast to gRPC, which we will cover in the next chapter, there is no need to define additional logic for converting data. An example for a frontend function calling a function from the backend would look like this:
+Calling backend functions from the frontend is pretty straightforward. In contrast to gRPC, which we will cover in the next chapter, there is no need to define additional logic for converting data. An example of a frontend function calling a function from the backend would look like this:
 
 \begin{figure}[h]
     \includegraphics[scale=0.35]{img/trpc/pages.png}
@@ -55,12 +55,12 @@ The implementation of the \textsc{create} function on the backend looks as follo
     \includegraphics[scale=0.35]{img/trpc/server.png}
 \end{figure}
 
-When writing the code, tRPC manages to impress. The backend reacts to changes on frontend and vice versa. If both services aren't compatible during development due to the data structures not matching, for example, tRPC gives meaningful error messages. When you combine this with autocompletion and typesafety, also throughout client and server side, one can only describe coding in tRPC as convenient.
+When writing the code, tRPC manages to impress. The backend reacts to changes on the frontend and vice versa. If both services aren't compatible during development due to the data structures not matching, for example, tRPC gives meaningful error messages. When you combine this with autocompletion and typesafety, also throughout the client and server side, one can only describe coding in tRPC as convenient.
 
 \pagebreak
 \section{GRPC}
 
-As a Remote Procedure Call framework, gRPC allows multiple services to call each others functions. We use it to transfer data from TypeScript to Rust and the other way around. In general, gRPC supports many more programming languages.
+As a Remote Procedure Call framework, gRPC allows multiple services to call each other's functions. We use it to transfer data from TypeScript to Rust and the other way around. In general, gRPC supports many more programming languages.
 
 To achieve this, gRPC requires the arguments and the return value of the function to be defined in a separate protobuf file. Protobuf can be regarded as its own language and has its own data types. The protobuf file for our project looks as follows:
 
@@ -103,7 +103,7 @@ and crafts a response.
 \pagebreak
 \section{Comparing tRPC, gRPC and REST}
 
-TRPC keeps the developer on a short leash. Moving within the radius, however, is very convenient and feels efficient. It is a framework with focus, as it only allows TypeScript as a programming language. But with this restriction comes ease of use, typesafety and a fluent full stack coding experience. In real world projects, tRPC will most likely not be able to carry out all tasks, but is well-suited as a basis to build on top of.
+TRPC keeps the developer on a short leash. Moving within the radius, however, is very convenient and feels efficient. It is a framework with focus, as it only allows TypeScript as a programming language. But with this restriction comes ease of use, typesafety, and a fluent full-stack coding experience. In real-world projects, tRPC will most likely not be able to carry out all tasks, but is well-suited as a basis to build on top of.
 
 GRPC, on the other hand, offers more flexibility at the price of a few extra steps. Most commonly used programming languages are supported, but data always has to be converted into gRPC's own format and back. When the schema is changed, the project has to be built anew. But writing the protobuf file is far from complex and building is fast enough to not be cumbersome.