Full Stack Web Development

Full stack web development entails many dozens of moving parts. Moving parts in both the front and backend. Full stack web development will vary from one company to the next. It’s not industry centric. Nor is there an exact roadmap to follow. Moreover, the technologies used to accomplish thereof will change as well.

Full stack web development cannot be taught in entirety in a bootcamp or an online class(s). To fully grasp the idea and grow our skills in this rapidly changing arena, we need experience. Experience building complex UIs with powerful frameworks such as React and Angular. It can also be beneficial to know what’s happening under the hood of these frameworks shall there be a problem. Which is why it’s wise to know TypeScript and JavaScript. To have built a variety of small and large apps;

Same goes for the backend. Some companies use Spring while others use C#. My last company used Node and Spring Boot. Before that I worked briefly with Django. I recently took on a large endeavor with Node and Mongo. Sure, many of the concepts are similar. But syntax, error handling, deployment, and many other tasks are quite different.

Layouts

Layouts are a crucial part of full stack web development. They serve as the basis of the entire project. Regardless of how complex or basic the frontend is, every app needs layouts. These may begin as a sketch done on paper or with the program, Sketch. Adobe and many other companies have programs for designers to quickly add drop downs, forms, etc.

Thereafter these low fidelity concepts go to legal teams and stakeholders for review. Sometimes low fidelity mocks are bypassed moving directly to high fidelity. Some have fonts and pixel dimensions while others don’t. Adobe XD is a good tool, but can be frustrating to meet the designers exact pixel dimensions.

Layouts not only serve as a visual guide. They also provide developers a way to see exactly what the features are and talk about how they’ll be built. How will data flow from one page to the next? What backend calls need to be made? This is the time for dev discussions to flourish.

Frontend Development

Frontend development is usually stage two in my experience. Once layouts are approved and revised, components are created. Some of which may come from a library while others are developed from scratch. Services are written which may house reusable functions or serve as middleware. Middleware that sends and receives data or makes http requests.

TypeScript for instance frequently uses RxJS to refine payloads. Observables are meant to share/ broadcast values. Services are generally where devs will make API calls, save, and revise data. Every framework has services. Generic files can be created in vanilla JavaScript apps that, conceptually do the same thing.

Frequent frontend challenges during full stack web development include but are not limited to error handling, getting values to populate at the right time, or general speed and performance. Frontends can get very complex. Or they can have a minute UI with a complex backend.

CSS

I don’t believe I’ve ever met a developer that enjoys CSS as much as I do. Maybe it’s because I began my career building rich media units. Rich media were often times rather fun and creative endeavors that entail animation, graphics, unique tracking systems, and easy API payloads. Moreover, so much of my dev experience has entailed crazy complex UIs, so I got darn good at CSS and SCSS.

But I digress. CSS can get quite unwieldy. I’ve seen dedicated full stack devs who insist on writing inline styles or simply don’t know how to write CSS at all. I usually alphabetize my styles and very cognizant as to which should be in their own namespace and what styles should be global.

Naming conventions are also very important. So is careful attention to swapping out classes or over riding rules. In addition to deleting unused classes. Keeping CSS and SCSS files very tidy is big time important. We can optimize styles via libraries, importing styles, and using variables. Just to name a few.

Responsive Content

Responsive content undoubtedly resides on the frontend. This is the process of conforming everything to the screen size. Regardless of where I work, I usually see Bootstrap used. And it drives me nuts because so many devs think it’s ok to use an entire library just to make columns. Bootstrap gets in the way of everything in my opinion. I avoid it all costs.

Instead, I do everything manually to obtain full control of the UI at any size. This is done by either adding breakpoints or using a service and an observable. Something simple that automatically calculates the width.

@media screen and (max-width: 1300px) { }
@media (min-width: 1200px) and (max-height: 700px) { }
@media screen and (max-width: 992px) { }

// Set a resize event on a parent
host: {
   '(window:resize)': 'onWindowResize($event)'
}

// Set the values
someWidth: number = window.innerWidth;
private winWidthSource = new BehaviorSubject(this.someWidth);
currentWidth$ = this.winWidthSource.asObservable();

// Update the width
changeWidth(newValue: number) {
  this.winWidthSource.next(newValue);
  return newValue;
}

// subscribe/ broadcast the new values
this._service.categoryNavigationMenu$.pipe(takeUntil(this.unsubscribe$))
   .subscribe((val) => {
      val ? (this.fullExplanation = false) : '';
   });

// Use the value
*ngIf="screenSize > 605"

Responsive content can be extraordinarily difficult at times. In my experience, UI’s can be drastically overhauled in each layout. In turn, the frontend needs to be malleable and maintained with precision. Otherwise, things get very messy, quickly. UI command at this level is usually done by a Sr. UI Engineer or Frontend Developer.

Error Handling

Error handling is very important in full stack web development. Everything in this category boils down to UX and information architecture. A users experience determines if they purchase a product. Whether or not they sign up. Whether they leave the site altogether and do thereof to the nearest competitor. Information architecture is similar.

If errors occur in said processes, users need to know about it. Form field errors should execute before form submission in my opinion. Some sites don’t even have inbuilt form error handling, making the process beyond frustrating. Especially if it’s a government website or something mandatory like car registration.

Errors can be displayed as notifications, top and centered, or any other way that jives with the UI. They may come from the frontend such as in the case of a form. Or a 500 error from a failed API. 500 errors can be used for anything users don’t need to know about. Just something indicative of a problem beyond their ability to fix. Some errors will have a code such as 401 while others are strictly UI related.

Documentation

Ugh, documentation. Is it safe to say, it’s rare to walk into a new place and there’s ample documentation available? Has anyone experienced this? What’s your opinion on documentation for proprietary software? What about APIs? Have you found that most or many APIs are well documented?

For two years now, I’ve been working at a financial institution. And the documentation is far from perfect. The documentation in a library I work with has a terminal command for major and minor which definitely helps. I believe it looks at the branch changes and decides what it should be bumped up to (1.2.1 or 1.2.4). Run the major terminal command and it bumps it to 2.0.0.

Large companies often use Confluence. This is massive system that enables anyone with access to create new pages. It’s like an internal blogging solution. Teams create docs on their endeavors. Stakeholders create docs on protocol. And admin create docs on URLS, logins, permissions, etc.

I’m currently working on documentation for a massive single page app I’ve created. I’m sure there’s a dedicated industry format, but I simply think it’s wise to include explanations on features, payloads, APIs, and perhaps components.

OAuth

OAuth will most likely be a part of any full stack web development project. Upon it’s inception, the goal was to create a system where users were not forced to enter their login credentials to third party apps. Before OAuth, apps would ask for third party login credentials in order to connect users’ contacts. And because many users will do anything to do thereof, they’d be happy to fork over their username and password. This may be “safe” in some cases, but…it’s a terrible method.

I once read an analogy but don’t know who to credit (apologies). When we check into a hotel we provide the front desk with an ID, credit card, etc. We’re then given an access card that opens the room. It also opens the pool, the gym, and numerous other areas on the property. But the only one who knows our true identity is the front desk. This is the concept behind OAuth.

The benefit of this process is companies don’t need to trust developers with login credentials. Users are sent to a proprietary OAuth server to login. This process limits security vulnerabilities. In turn the attack surface is greatly reduced. If users need to enter their password in multiple locations, attackers have more opportunities to steal passwords. Moreover, this leads to one location to build on OAuth. Such as multi factor authentication. OAuth enables features like this to be built and maintained in one location.