Apply suggestions from code review

Co-authored-by: Varsha <[email protected]>

docs/book/src/getting-started.md

@@ -38,12 +38,12 @@ kubebuilder create api --group example.com --version v1alpha1 --kind Memcached -
 
 ### Understanding APIs
 
-This command's primary aim is to produce the Custom Resource (CR) and Custom Resource Definition (CRD) for the Memcached Kind. It creates the API with the group cache.example.com and version v1alpha1, uniquely identifying the new CRD of the Memcached Kind. By leveraging the Kubebuilder tool, we can define our APIs and objects representing our solutions for these platforms. While we've added only one Kind of resource in this example, you can have as many Kinds as necessary. Simply put, think of CRDs as the definition of our custom Objects, while CRs are instances of them.
+This command's primary aim is to produce the Custom Resource (CR) and Custom Resource Definition (CRD) for the Memcached Kind. It creates the API with the group `cache.example.com` and version `v1alpha1`, uniquely identifying the new CRD of the Memcached Kind. By leveraging the Kubebuilder tool, we can define our APIs and objects representing our solutions for these platforms. While we've added only one Kind of resource in this example, you can have as many `Groups` and `Kinds` as necessary. Simply put, think of CRDs as the definition of our custom Objects, while CRs are instances of them.
 
 <aside class="note">
 <h1>Getting a better idea</h1>
 
-Consider a typical scenario where the objective is to run an application and its database on a Kubernetes platform. In this context, one object might represent the App, while another denotes the DB. If we define one CRD for the App and another for the DB, we uphold essential concepts like encapsulation, the single responsibility principle, and cohesion. Breaching these principles might lead to complications, making extension, reuse, or maintenance challenging.
+Consider a typical scenario where the objective is to run an application and its database on a Kubernetes platform. In this context, one object might represent the Frontend App, while another denotes the backend Data Base. If we define one CRD for the App and another for the DB, we uphold essential concepts like encapsulation, the single responsibility principle, and cohesion. Breaching these principles might lead to complications, making extension, reuse, or maintenance challenging.
 
 In essence, the App CRD and the DB CRD will have their controller. Let's say, for instance, that the application requires a Deployment and Service to run. In this example, the App’s Controller will cater to these needs. Similarly, the DB’s controller will manage the business logic of its items.
 
@@ -124,7 +124,7 @@ From: `config/crd/bases/example.com.testproject.org_memcacheds.yaml`
 
 #### Sample of Custom Resources
 
-The manifests located under the "samples" directory serve as examples of Custom Resources that can be applied to the cluster.
+The manifests located under the "config/samples" directory serve as examples of Custom Resources that can be applied to the cluster.
 In this particular example, by applying the given resource to the cluster, we would generate a Deployment with a single instance size (see `size: 1`).
 
 From: `config/samples/example.com_v1alpha1_memcached.yaml`
@@ -215,7 +215,7 @@ func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (
 log := log.FromContext(ctx)
 
 // Fetch the Memcached instance
-// The purpose is check if the Custom Resource for the Kind Memcached
+// The purpose is to check if the Custom Resource for the Kind Memcached
 // is applied on the cluster if not we return nil to stop the reconciliation
 memcached := &examplecomv1alpha1.Memcached{}
 err := r.Get(ctx, req.NamespacedName, memcached)