This weekend I finally decided to do something about my aging website. Initially, my thoughts were to update the design, maybe tweak some of the content. Alas, there comes a point where a complete rewrite is demanded. My site, built in 2010, was one of those version 1.0’s that could not be saved by a new coat of paint, refactoring, or content updates.
My blog had gone stale. Even the posts from back then were not worth hauling over. My last post was in November of 2011, when I thought building a web application in C++ might be a good idea.
As our past shapes us, I thought it only appropriate that my last blogs shall shape these first few posts. A tribute of sorts–where I was at the start of the decade, contrasted to where I am now and more importantly where I and my relationship with technology are headed. Below are a few highlights from my favorite age-old posts.
August, 2010 – Zend ACL and How To Create a Simple Login
Zend Framework 1. What sweet memories. My first introduction to legitimate MVC frameworks and architectural design patterns. Zend framework and my work around it matured me more as a programmer than any other moment in my history as a developer. It was at the same time that I fell in love with domain driven design, learning from the philosophies of Eric Evans and Martin Fowler.
Zend Framework had a steep learning curve at the time. And I wanted to help developers jump right in to securing their ZF web applications, using the ACL library. I also talked about how to build a decoupled namespace, where the core of the logic should live, while utilizing only the pieces of ZF that were necessary. Keep in mind that PHP didn’t actually have namespaces at the time. So classes tended to have very long names.
ZF was difficult because it was one of the most flexible frameworks of its time. The ZF team didn’t want to be overly descriptive on where your application logic should live. Compared to CakePHP’s version 1, or even worse, CodeIgniter.
My first blog on this new site will share a similar topic. But instead of describing how to build a login flow for the latest Zend Framework version (which is 3 by the way), I want to walk through a microservices project, where the first part is building an OAuth 2.0 service.
When a user logs in, she is authorizing the client (a browser in this case) to communicate with the backend API’s on her behalf, utilizing a token that is stored in a cookie.
Though the OAuth flow seems similar to the old fashioned login flow, where a session id is created instead of a token and stored in the browser, also commonly using a cookie, there are a few distinct differences.
With OAuth backend API’s, once the request hits the API, the API can assume the request is authorized. The backend doesn’t need to worry about session management. This is because the OAuth service catches each request and will only pass it along if the OAuth token is valid.
Removing the whole authentication/authorization piece from the backend API simplifies the application code, allowing the service to achieve an ideal state of serving a single, clear purpose. In the microservice world, this singular purpose allows you to build manageable, flexible components. This leads to faster iterations, less daunting code bases, and the option to vary your development language case by case.
To be continued…