Category Archives: CS@Worcester

FRONT/BACK ENDs

The blog entry “Front-End vs. Back-End Explained by Waiting Tables at a Restaurant” breaks down the differences between front-end and back-end development in a straightforward, humorous, and visually appealing manner using an everyday scenario. The front-end is likened by the author to a waiter in a restaurant, who deals directly with customers and is in charge of communication, presentation, and ensuring that they receive what they want. The back end is compared to the kitchen, where the actual cuisine is prepared by the chefs (or servers, databases, and business logic). Although the kitchen is not visible to patrons, the restaurant cannot operate without it. The article also describes how APIs function similarly to a menu, outlining exactly what can be requested and how the restaurant would react. For novice engineers, this example helps make difficult technical concepts more understandable.

I picked this article because it directly relates to the concepts we have been covering in class, the transition from monoliths to client-server and ultimately microservices. We witnessed firsthand how the front-end and back-end communicate through well-defined paths in our Microservices Architecture exercise. For example, the StaffBrowser or AdminBrowser interfaces with the GuestInfoBackend, InventoryBackend, or ReportingBackend. Each backend service mimics the kitchen/waiter structure outlined in the article by processing data and returning results to the browser. The article’s description of how requests go through the system is consistent with even the API endpoints we looked at, such as CheckInGuestFrontend or the Express.js servers that power each system. Knowing this example made it easier to understand why our class project is divided into several components and why there needs to be exact communication between them.

As I thought about the post, I saw how crucial it is that both front-end and back-end engineers comprehend their responsibilities and the connections between the systems. Separating responsibilities makes systems easier to maintain, scale, and debug, as we discovered when we compared the monolith versus microservices models in class. The essay reinforced the point by demonstrating how, similar to a restaurant, uncertainty at the front-end or back-end results in delayed service, mistakes, and disgruntled customers, in this case, users. I was also reminded of the importance of APIs. We were effectively looking at the menu that specifies exactly what the front-end can request and how the server will reply when we examined the OpenAPI definitions and backend endpoints in our code. I want to use this example going forward whenever I create or work with APIs. It will be easier for me to organize cleaner services and interact with coworkers if I know what belongs in the “kitchen” and what belongs in the dining room. I want to focus more on how front-end requests move through the various back-end systems and how each service does its function on its own as we continue to work with microservices.

Front End v. Back End Explained by Waiting Tables At A Restaurant

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.

A quick look at front-end

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well.

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense.