Since our capstone project next semester will offer roles dealing with both frontend and backend, I thought it’d be a good idea to do a bit more research on each type of web development and how they compare to each other. Backend and frontend will be very relevant to me in the future as many jobs catered to software development involve working on either the frontend, backend, or both with full-stack. We also ran out of time this semester and did not get to fully cover the frontend, but a blog I found on CareerFoundry offered a good rundown on what frontend really is, as well as backend.

Frontend

Frontend is what you see on the screen of your device. It is the client-side. When working on the frontend, the languages you will most likely use are HTML, CSS, and JavaScript. CSS complements the HTML code by defining the style of the website’s content. It deals with the layout, colors, fonts, and more features of the website. Common tools that ease the tasks of the frontend developers include Express, Angular, JQuery, DJango, and SASS. 

Not Web Design

Frontend development is not the same thing as web design. A web designer focuses on designing the aspects of a website, whereas a frontend developer takes that web design and adds functionality to it using the previously listed languages.

Frontend Without Backend

A website is said to be static when the content of the site doesn’t really change. All necessary information that determines what’s on the website can be found on the frontend. This is good if you want to showcase your business or professional profile. In order for the website to be interacted with, the website needs to include a backend.

Backend

For the majority of the semester, we have worked on activities and assignments related to the backend. Common languages used in the backend are Ruby, JavaScript again, Python, and Java. In this class, we used JavaScript to write in backend code. Popular tools include Node.js, MongoDB, Flask, and PostgreSQL. We experimented with the Node.js environment and the MongoDB database in our work for this class.

Which One Should You Pick?

If you like the idea of working with visual designs and adding real actions behind them, creating a smooth easy-to-access experience for the user, frontend is the way to go. If you enjoy working with data, solving algorithms, and finding solutions to optimizing complex systems, backend may suit you more. However, if both descriptions fit you and are proficient on both sides, then you may be able to do both! A developer who is proficient in both the frontend and backend is known as a full-stack developer. But whichever path you choose to go down, understand that one cannot work without the other when developing a website.

Blog

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Using Rest API in class while working with our in-class and homework assignments has helped me understand backend development in a practical way. Vaibhav Kandwal’s blog, “REST API Tutorial – REST Client, REST Service, and API Calls Explained With Code Examples” does a really good job of simplifying and giving a top-down overview of what it looks like. Throughout my semester in Software Construction, Design, and Architecture I’ve learned a lot about Rest APIs but Kandwal’s way of breaking it down has deepened my understanding further.

One of the biggest points made in the blog is that Rest APIs are built around the idea of resources. Instead of being stuffed full of complicated actions, everything instead becomes a resource that can be created, retrieves, updated, and deleted. This makes endpoints easy to understand as when you see something like /guests you know what to expect. GET gets the data, POST adds something new, PUT or PATCH updates it, and DELETE removes it. REST reduces the guesswork by having a consistent structurer to follow.

The blog also heavily emphasizes that REST APIs are stateless. I wasn’t entirely sure why this was the case at first but after reading through it makes sense now. “Statelessness: the communication should have no client context stored on server. This means each request to the server should be made with all the required data and no assumptions should be made if the server has any data from previous requests.” The reason this is so important is scaling becomes much easier. The server doesn’t have to store anything about the previous requests. This also has the added benefit of system reliability. When the server doesn’t have to keep track of any previous conversations, there are fewer opportunities for unexpected bugs. This creates a safer and well-organized approach.

This connects directly with what we’ve worked with in class. One of our more recent homework assignments was created the endpoints in the Specification.yaml file and it was easy to see how each one followed the same structure with minor differences depending on the requirements for that endpoint. We decide what our resources are, what each endpoint should do, and what kind of data each operation should accept or return. Having that structure laid out before me has increased my understanding of the backend logic and made it much easier when it finally came time to write the JavaScript.

Overall, after reading this article I have a deeper understanding or REST APIs, and I plan to take this with me into my future career. I will certainly need this knowledge next semester when I take my Software Development Capstone course but also after I graduate seeing as how I have my sights set on being a software developer.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

https://github.blog/news-insights/octoverse/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025/

For this blog, I chose to read Github’s 2025 Octoverse article, “What 986 Million Code Pushses Say About The Developer Workflow in 2025.” The article analyses nearly a billion commits from developers around the world and highlights how software development teams are adapting their workflows as the entire CS landscape continues to change and evolve. I selected this article because it felt directly related to what we’ve talked about in CS-348, particularly how processes like CI/CD shape development practices and how Agile could potentially relate to some of the points Cassidy Williams, the author, brings up about teamwork.

One of the central ideas is that “iteration is the default state.” Instead of shipping big releases occasionally, developers should instead push small parts constantly. The article explains how smaller and more frequent commits have become normal. Developers fix a bug, build a small feature, or tweak a config, and then push. These smaller, lightweight commits lead to smaller, more focused pull requests with a single purpose. The article also emphasizes that constant shipping reduces risk because smaller changes are easier to debug and rollback.

The article also argues that communication patterns need to catch up with development and workflow changes. Some of the fundamental change that Williams believes need to happen in order for communication to keep up with development include: Standups being shorter or asynchronous entirely, they state that pull requests being blocked is no longer acceptable, and hiring needs to shift towards people who ship the fastest. In William’s look-ahead at the end of the article, they mention how “AI fatigue” is real but, that in the end, the best tools will win out.

Reading this made me think pretty critically about my own habits. I have always waited to commit until I felt a feature was worth committing, until it felt “big enough.” This article helped me realize that the size of a commit is entirely arbitrary and has nothing to do with the importance of a commit. More frequent commits are better for safety and for collaboration. I also realized that I have heavily underused feature flags and often think of tests and an entirely separate act that development when in reality they should be tightly connected and done pretty much constantly. Looking forward, I want to adopt the practices mentioned in this article, lightweight commits, strong integration and deployment, and clear communication can hopefully help to bridge the gap between communication and development.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

Link: https://blog.codinghorror.com/code-smells/

In the blog post “Code Smells” by Jeff Atwood, he proposes an argument that it is very important for programmers to develop a “code nose,” which essentially is the ability to sense when code is beginning to rot before those bugs even appear. Atwood goes through a long list of common smells within classes, such as long parameter lists, duplicated code, overly long methods, and giant classes that simply try to handle too many responsibilities. He also describes smells that are between classes. This includes primitive obsession, where basic types are being overused instead of proper classes, as well as data classes that only store fields but have no behaviors. He also describes feature envy, which is when one class is constantly reaching into another class’s data. His main point is that while refactoring tools and books is helpful, the real key is to learn how to notice these warning signs in your own code.

I chose this topic because I feel like I didn’t get a great understanding of code smells in class, so I felt like it would be beneficial to get a better understanding of it. This blog post was very resourceful, as it reminded me that readable and maintainable code is just as important as whether or not the code is functionable. Sometimes, I get too focused on making sure that the code just works but I don’t pay attention to the readability or maintainability aspect of it. Reading about code smells made me realize that some of these habits apply to my own work. I have definitely been guilty of data clumps before, as sometimes I pass the same group of variables through multiple functions rather than bundling them together into a class. I’ve also definitely done the long method smell before too, as sometimes I keep lumping stuff into main() rather than creating helper functions which makes it more readable and easier to maintain.

Going forward, I plan to use this list of code smells as more of a mental checklist whenever I am working on a group project or assignment. This will improve my own code by making it more readable and maintainable, but will also prove to be beneficial in a workplace environment. In my career, this will help me navigate potentially unfamiliar code bases, and will even help me leave code cleaner for my coworkers. Overall, understanding code smells will prove to be beneficial for myself as well as my potential future coworkers.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

I have never worked on front end development until now. My preconceived notions made me think this would be simpler like web design, but I was wrong. This is the piece that the users interact with directly. Mistakes here make the project look sloppy, reduce user satisfaction, or can make it hard to navigate. The front end is the first impression, if this leaves a bad taste, then it may lower user satisfaction.

Front end development relies on three things, html, css, and javascript. HTTPs give us the skeleton of the page. It shows where our elements like headers, images, and links go. CSS takes what we have and stylizes it. This handles things like colors and layers. This is also responsible for ensuring the front end looks good on whatever device it is ran on. And finally java script introduces dynamic behaviors. This can include dropdown menus, data fetching, animations. This pulls everything together to create a responsive UI.

There’s a lot of good front end tools to check out. Tailwind css allows you to simply learn styling patterns that work, without having to write full css files. Bootstrap is a css framework that provides pre-built ,https, javascript and css components. Apparently 19% of all websites were created with this. Css loaders give you hundreds of loading animations that you can use in your projects. Coolers are a pallet generator. This allows you to see a variety of color pallets to choose from so you can see what you link and implement into your front end. A lot of these tools seem very interesting and have gotten me more interested because they seem very simple to implement while making your project look cleaner. These tools don’t exist to replace doin the work yourself. These are in place to support the core aspects of front end development. Some of these tools will help you build a layout faster, and other tools like codepen allow you to test without having a complete project. They give the developer some simple quality of life improvements that can make the process more streamlined.

https://www.wearedevelopers.com/en/magazine/210/best-tools-for-front-end-development

https://martijnhols.nl/blog/accessibility-essentials-every-front-end-developer-should-know?

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

In building software, it’s easy to focus on writing code, making features, and getting things working. But real, maintainable systems require more, they require thoughtful architecture. In the article “Five Architectural Principles” posted in the Criteo Engineering blog on Medium, Peter Milne lays out five foundational principles that, in his experience, guide sustainable and scalable software systems. The article is short but it outlines an architectural mindset that feels especially relevant.

Milne begins by outlining five principles he believes lead to more maintainable systems, grounding each one in how teams can better structure software over time. He doesn’t claim that implementation is unimportant, but he does consistently direct attention towards fundamental architectural choices. That emphasis made me reflect on how many of my past projects became unmanageable messes simply because I was focused on writing code rather than the structure supporting it.

One of the principles that Milne discuss is the important of designing components around well-defined responsibilities. He explains that keeping components focused on a single purpose helps reduce unnecessary complexity as systems evolve. His explanation made the idea more concrete for me, especially because it aligns with some of what we’ve learned in class about separation of concerns and the value of components that can change independently.

Milne also emphasizes the importance of clear contacts, the rules or interfaces that describe how parts of a system should interface. He presents contracts as a way to maintain stability, even when internal implementation details change. His explanation made me think about much smoother some of my past group projects would have been if interfaces had been clearly defined from the beginning.

Milne also makes it clear that architectural decisions should be intentional rather than accidental. He doesn’t prescribe strict formulas, but he encourages thoughtful design so that systems can evolve without becoming overly complicated. That perspective resonated pretty heavily with me because it connected to an overarching theme that’s been prevalent throughout 343: the choices we make early on influence how well a system can adapt in the future.

Reading this helped me rethink the way I want to approach future projects. Instead of immediately writing code, I want to start by defining boundaries, identifying responsibilities, and agreeing on interfaces. Architecture is meant to support the system, not struggle to keep up with it. Even though Milne’s article is fairly brief and pretty corporate, it made me realize the value of the invisible structure supporting the visible behavior of software.

https://medium.com/criteo-engineering/five-architectural-principles-d32dc2bfefae

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

For this blog I chose to explore the article “REST API Design: Architectural Foundations and Modern Practices” by Nikola Lazarov. Since CS-343 focuses on software construction, modularity, and clean interfacing, I wanted to learn more about how REST APIs fit into architecture beyond the basic GET/PUT/POST/PATCH commands. Lararov’s article stood out because it connects the roots of REST with other practical API design conventions we’ve learned in 343.

Lazarov begins by grounding the discussion in the original REST constraints defined by Roy Fielding. These include ideas such as statelessness, a uniform interface, resource-based design, and layered system architecture. The article then explains how these constraints influenced real world API design today. He connects these constraints directly to the goals of scalability, simplicity, and clear separation of concerns. For example, the statelessness requirements means that each request must contain all the information the server needs, which helps a system scale because servers don’t need client-specific context. His explanation in the article helped me understand that REST is a set of architectural decisions that influence how the entire system behaves and it isn’t nearly as independent as I thought.

The article also discusses how to apply REST principles in API design. Lazarov highlights the importance of resource-oriented URLs and matching HTTP methods, GET for retrieving, POST for creating, PUT for updating, and DELETE for … deleting. He also greatly emphasizes using meaningful HTTP status codes to communicate consistently. These design choices might seem small, but that’s kind of the entire point, these choices contribute to APIs that are predictable and easier for clients and developers to understand. Rather than presenting REST as a rigid formula, Lazarov explains how these principles guide the structure of modern APIs, helping developers create interfaces that are both intuitive and aligned with broader architectural goals.

I selected this article because I believe that it directly ties into topics we’ve explored in 343. REST APIs are essentially interfaces between components of service, so understanding why they are designed the way they are is directly relevant. I also wanted a source that explains the “why” behind REST’s patterns instead of just the “how.”

What I learned most from this article is how intentional REST API design is and what it should look like. I had previously thought of endpoints of pretty arbitrary choices, but Lazarov’s explanation helped me understand that each part of an API should reflect the underlying REST principles.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.