I wanted to do my first post on the first pattern we are given in chapter 2 because it is the start of delving into the patterns we will be working with after chapter 1 and start of chapter 2 introducing what the book will be about. The first pattern here is “Your First Language”, and it talks getting started with programming languages and how you can start and improve at working with one. It is recommended to start with one language and take time to learn and get used to it so that you are fluent in it. Solving problems using this language can also help you gain experience and get a better understanding. You will want to spend enough time with the language to become fluent in it, but keeping the introduction to the book and chapter 2 in mind, you don’t want to get stuck with it and instead want to be able to learn other languages after the first one.

I think that it is smart to focus on one language when starting out before moving onto others, and having problems to solve with that language can be very helpful at understanding and working with that language. It reminded me of doing worksheets or assignments in school for a subject after doing studying and some practice. It is also good to not start trying to learn multiple languages at once because some of what you learn from them may start to get mixed up, and starting with one language before moving onto others and possibly doing multiple languages simultaneously is the smarter route to take. In my past CS courses, we were taking time with a language before moving on the next one, working on and solving problems with that language. Because of that, I have seen how effective this way of learning languages is.

I thought that this was a great first pattern and problem to go over after the first chapter and the second chapter’s introduction, since this book is going to go over many other patterns in this chapter and later chapters, and this pattern covers the starting point for readers and programmers learning new languages.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

I wanted to focus my last blog post on frontend development because I think I have a better understanding of the backend than the frontend, and while I think I get how the frontend works and what is going on in it, I was having trouble in the latest activity adding to the frontend that we were given and connecting it to the backend. I also had to make some edits to my assignment and could talk about what I had trouble with.

First, with the last homework assignment, I had a few issues with adding onto my frontend. When I made the new filterByName button, I did not add it to the data() section, which would cause an error. I added the button and the status I used for it to the data() section and gave them default values similar to what was already there. My other two issues had to do with my filterNames method, where I was stating the endpoint to get names incorrectly, and I had the resulting response given to the wrong variable. I was a little stuck at first changing my endpoint name because at first I changed it to just /items instead of items/{name}, which I had before and is not the correct way to get to the endpoint. I was trying to add a name variable to the get method as a way of getting the names, but after looking through the frontend example, specifically versions v2 and v3, I saw that I could just connect to the names of the items endpoint with /items + itemName. The last issue was sending the response to the wrong variable because I had it set to just a names variable, but I changed it to a filter variable to show that the result is being given to the resulting filter, not changing the actual names in the endpoint.

I also did some more into endpoints to see if there was anything I was missing when it came to understanding the frontend. I read an article called “What is Front-End Web Development?’ by Trio Developers, and most of the article was a review of what I knew from the previous article I read for the blog: The frontend makes up the interface of the program that users interact with, and the frontend uses different elements that can be interacted with to go through the site, such as drop down menus and sliders. The frontend is immersive for the user interacting with the site.

The article goes on to talk about what frontend developers do, and their jobs focus on developing interfaces for code, improve upon applications, and work on UI/UX designs and their usability/feasibility. It also goes into the differences between the frontend and backend, but I already talked about those in the previous blog post.

I think I correctly fixed my mistakes on my homework assignment, and while the information from the article was mostly review, it was still a good read and I liked how it talked more about developers and what their jobs are.

https://trio.dev/blog/front-end-web-development

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

I wanted to do my next blog post on backends and frontends because we learned about them through the past few activities and while I have a general idea of how they operate, I want to clear up some confusion and get a better understanding of them. I was having some technical issues with my Visual Studio Code and Docker while working on those activities and spent some time getting them working, so I feel that I missed out on some parts of the work.

Based on the activities and my own understanding before doing more research, I saw the backend as the background code that makes the program work, while the frontend is what the user interacts with and uses the backend. The backend works with the API, endpoints, and paths that use the HTTP methods. The frontend works with the application and design, as well as being the interface for the user. They cooperate to run programs because they worked together in the activities to run the LibreFoodPantry data.

When looking more into the frontend and backend from an article from GeeksForGeeks called “Frontend vs Backend”, it was saying similar things about the two that were covered in the activities with the frontend and backend working as client and server sides of a program respectively. The frontend is the client side that the user directly interacts with, while the backend is the server side that runs the program and manages the data. The programming languages that the frontend uses are HTPP, CSS, JavaScript, and the ones that the backend uses are PHP, C++, Java, Python, JavaScript, Node.js, C#, Ruby, and REST.

As mentioned earlier, the frontend and backend sides act as two sides of a program that work together, with the frontend being what the users interact with, while the backend is not able to be seen by users but runs the code and even though it is not directly interacted with by the user, it runs what is interacted.

The main frameworks that the frontend uses are AngularJS, React.js, jQuery, SASS, and Flutter. The main frameworks that the backend uses are Express, Django, Rails, Laravel, and Spring.

I learned more about the fronted and backend aspects of web development through this article and reviewed what I knew from the activities that I may not have understood because I had to dedicate time to fixing the program so I could actually test it. I have a good understanding of how to work with the backend and frontend of a program, and can continue working on activities and homework.

https://www.geeksforgeeks.org/frontend-vs-backend/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

After doing more work with activities 13 and 15 and working on homework 4, I wanted to read more about how to use the http methods with REST API calls because I was having some trouble understanding how to implement them in the homework at first and wanted to get a better grasp on how they work to set up my endpoints and paths.

I have decent understanding of each of the methods and how they correlate with the paths and endpoints we have been working with so far. The main source I used for reading more about the methods was the REST API tutorial about http methods. It goes over each of the methods and gives a summary at the end which is a table. It also gives a brief glossary over some terms used and references to other sources. It gave good explanations for each method and was divided in evenly sized sections.

The main five methods used that we are familiar with are GET, PUT, POST, DELETE, and PATCH. GET is used to find and return an item or object based on the parameters we choose, like a name or ID. POST creates an object and posts it to the data. PUT updates and replaces data for an object. DELETE removes/deletes an item/object. PATCH is used for minor/partial updates. We have not used PATCH in our activities yet, but it did show up as a method in an example given for activity 12 for how http methods work with urls.

Going more into the methods, GET methods are considered safe methods because they do not make any changes to the data, and they are also idempotent because they are expected to allow multiple similar requests with the same results. The other methods all change the code or data in some way, so they are not considered safe. DELETE is the other idempotent method because the result of each DELETE is a removed object. PUTs and PATCHs seem the same because they both are used to make changes to existing data, but they differ how much they update. PATCHs are for smaller and partial updates, while PUTs are for bigger updates and usually involve replacing existing data.

After this reading and doing more work with REST API, I have a better idea on how to implement them in code and continue with the activities and homework.

https://restfulapi.net/http-methods/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

I wanted to read more about REST APIs after working on them with the past couple activities and having some questions about them due to some mistakes I was making. I was getting a better understanding of the concept as the activities continued on, but there are some things I wanted to clear up based on what I was wrong about or had trouble understanding at first.

From the activities, I know that APIs are used for applications and build them with code. A REST API is a version of an API that uses REST standards and constraints, which seem to work more with HTTP methods. When working on the activity, I kept confusing some of the methods and mistaking the API methods with the source paths. I was also a little confused at first about the request body after activity 12, but then after activity 13, I had a better understanding and it was basically the area of section in the request where you can enter the information for the method. For example, you can write the name and ID of items for creating an item, or you could enter a new name for an existing item given its ID.

I wanted to look more into what REST is about, and found a good article by RedHat called “What is a REST API?”, that goes over REST APIs and has a section just talking about REST. It is described as a set of constraints, not protocols or standards, and it is talked about how HTTP methods are used with it. It also talks about the multiple formats that HTTP can use with REST APIs, such as JSON, HTML, and PHP. The headers are considered very important because they contain identification data about the requests made, such as the URL and metadata.

Some of the criteria for an API to be considered “RESTful” is to have a client-server architecture, stateless communication, cacheable data, uniform interface for components, a layered system for organization, and optional code on demand. The uniform interface is also said to require that the requested resources can be identifiable and worked with by the client, have self descriptive messages, and available hypermedia. While there is a sizable set of criteria for an API to meet to be RESTful, it is efficient to use because it can lead to the API being faster and better to manage with the methods.

I have a better understanding of what makes an API qualified to be RESTful, and I see where I was making my mistakes in the activities.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

I wanted to read more about micro-services and monolith architecture after working on the recent activity with them and comparing and contrasting the two. They both have their benefits and have similarities, but there are important differences that make people question which is the better choice for designs that they are working on.

Monolith architecture has one database and is more contained, but is more risky to change and update because of how reliant it is on database. Microservices has two databases and has less risk because there is less reliance on each database and one that is getting changed will only affect up to half the system, while monolith risks the whole system being affected. Monolith is faster because it uses one database instead of two and less overall components, but micro-services is safer and better for larger or more complex systems. Microservices seems the better choice out of the two, but monolith has its benefits that should be kept in mind.

I wanted to look more into the two architectures and found an article “Microservices vs Monolith: which architecture is the best choice?” from N-iX, that went over the two and did more comparisons. Monolith was described as the default model for a while, but microservices was getting more traction and monolith is less used. The purpose of the article was to go over the two and decide if monolith is still useful and what it could still be used for.

More comparisons between the two were talked about as the article went over the strengths and weaknesses of both. The pros and cons that were already talked were mentioned, such as the risk of changing components in monolith and how microservices is better for more complex systems, but there were some that were either not mentioned or briefly talked about in the activity that show up in the article that makes the debate between the two architectures more even.

While monolith is more risky, it is more simple to work with and has less overall components to work with, which can make it effective for less complicated systems. It was also said that it is easier to debug and test monolith because it works as a single unit while microservices is multiple. Microservices is better with complex systems and can be easier to understand because of the division of the architecture with the multiple databases, and there is less risk with changes. Flaws of microservices are that it can get too complex, testing is more difficult, and has more cross-cutting issues.

In conclusion, monolith does still have its benefits and is better than microservices for simple and smaller systems, while microservices is better for complex and larger systems but would need more experience to use it efficiently.

https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

After working with docker in the past couple activities, I wanted to learn more about docker, particularly how docker uses images and containers after working with them in activity 6. I have a good idea on how they work and some differences between them, but I wanted to look more into images and containers to have a better idea and clear up some questions I had from the activity. The post that I read that talked about these two elements relating to docker and was helpful to me was “Docker Image vs Container: What is the difference?” from phoenixNAP.

Docker images are the executable files that have the source data for the containers to run, and the containers run by the images. Containers are environments in docker where users can interact with applications. Containers need images to run, and without a container to run, images aren’t very useful. Images cannot be edited because they are almost always in read-only mode, and can act as a preview to the container.

What I did not know about images was how an image can have multiple layers, with one of those layers being the base for the container. Unlike containers, they can not be stopped or run.

I knew that containers were the main places where you can interact with the program and incorporates standardization, but I did not know for sure that the visualization was taking place at the app level of containers rather than the hardware level. Containers are also autonomous and are very secure due to their isolation.

From activity 6, one of the main things I saw that separates the two is that containers have images as a part of them and when a container is created, both the container and image are created. But when the container is removed, the image stayed while only the container was removed. The image cannot be removed on its own because it is being used by the container, stopping the container will not allow this either.

One quote from the post that I think best sums up the relationship between the two is “When discussing the difference between images and containers, it isn’t fair to contrast them as opposing entities. Both elements are closely related and are part of a system defined by the Docker platform.” There are things that separate them, but images and containers aren’t meant to be compared and contrasted, but to be used together to efficiently run the programs and data given from the Dockerfile.

https://phoenixnap.com/kb/docker-image-vs-container

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.