For this week’s blog post I wanted to go with the “Backends for Frontends” (BFF) architecture pattern through Microsoft Azure’s documentation(https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends), having read the article in-depth since it gave me some food for thought.

The article explains how BFF works as an API design approach where each type of client; such as a web application, mobile app, or IoT device kind of communicates with its own tailored backend service. Instead of one universal backend trying to serve every kind of client, BFF splits the responsibilities across dedicated backend components. This lets each frontend receive data in exactly the structure and format it needs, without unnecessary complexity or over-fetching. The article also describes when BFF is useful, the problems it solves (like avoiding “one-size-fits-all” backend design), and its trade-offs, such as increased cost and operational overhead.

I guess I chose this resource considering how BFF connects directly to what we’ve been doing in CS-343 with REST APIs, Express endpoints, data validation using OpenAPI, and separating layers of an application. During the recent advanced assignment(referring to the REST API Back End Implementation homework of course), I had to build new endpoints, interact with multiple collections, and send changes to a message broker. That required some time of me thinking carefully about how different parts of the system communicate with each other.

The biggest takeaway for me was how the BFF pattern embraces specialization. Instead of making one giant backend do everything, you just got to let each client have a backend that fits them. This avoids exposing unnecessary fields, reduces client-side processing, and improves performance. It also aligns well with microservices, because each BFF can orchestrate multiple services behind the scenes. I realized that the structure of our assignments- frontend consuming API endpoints, backend handling logic, and MongoDB representing the persistence layer; is essentially a simplified version of this architectural thinking.

This article also made me reflect on situations where BFF might solve real problems i could probably encounter in the near future. For example, in our backend assignment, if we had a separate mobile client, its data needs would be very different from the web interface that interacts with full guest objects. A BFF layer could format responses appropriately, avoid over-fetching, and simplify the logic on the client side. The idea of tailoring backends to frontends also helps me make sense of why large systems separate responsibilities; it keeps things maintainable and avoids tightly coupled components.

So in short, i’d say that this resource strengthened my understanding of how backend architecture is shaped by client needs. It also helped me see the bigger picture behind concepts we’ve been using: validation, routing, endpoint design, and database access. Going forward, I expect this perspective to help me structure backend code more intentionally, especially when designing APIs that may evolve to support multiple types of clients.

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

Through my past couple blogs of Object Oriented Programming, REST APIs, and frameworks, I often came across the word “documentation” but commonly overthought it and didn’t do any more investigating into it. With that being said, I came across this blog 9 Software Documentation Best Practices + Real Examples and I feel a lot more comfortable with documentation as a whole. https://www.atlassian.com/blog/loom/software-documentation-best-practices

Imagine, you and your developing team are coding away on an application, but then an error appears, by which no one present knows how to solve it.

To solve this error, your options are:

1. Slack threads
2. Stack Overflow
3. Emails back and fourth 
4. Documentation 

The most promising answer of these options are documentation. With great documentation, you will get a clear precise solution to the problem you are facing. 

Now, what exactly is documentation? Documentation is written information that clearly explains the program’s structure, functionality, and when/how to use it; should be used as a guide or as a reference pointer for developers. If the documentation is done right, it reduces friction, boosts productivity, and helps the user understand the code from all angles due to the information of processes, functionalities, and solutions.

With so many benefits, documentation should be at the forefront of software developing teams, but unfortunately, it often gets overlooked. One of the main reasons for this is because documentation can go outdated very quickly. 

That being stated, here are nine ways to make sure your documentation will always be great:

1. Know your target audience
   1. General Audience (surface level) vs Developers (technical)
2. Keep it user-friendly
   1. Having a table of contents with clear headings can make it a lot more easier to find what the user is looking for
3. Use version control
   1. By doing this, you will be able to see all the latest updates
4. Incorporate visuals
   1. Some people are visual learners, who work better off of a video, photo and/or diagram (within reason)
5. Adopt a documentation style guide
   1. Consistent styling will make it easier for the user when going through each documentation type from said releasers (writers/developers)
6. Update regularly
   1. By doing this, your documentation will align with the latest software functionality
7. Encourage collaborative documentation
   1. Working together in person or remotely 
   2. Always good to have a peer’s input
8. Provide troubleshooting and FAQs
   1. This enables users to find solutions for common issues very effectively
9. Use documentation templates
   1. This will give a great start to all coming contributors of the documentation 

Overall, I really enjoyed this article and its purpose of making software documentation better. Furthermore, it mentioned how Google and Microsoft all stick to the same consistent documentation perspectively, which opened my eyes of how important consistency is in documentation within a company. Along with this, before “jumping” into something new, it will definitely be worth it to go over the documentation. Understanding and referencing any documentation is a skill.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.