Recently I was talking all things Front-End development (ES2015, Babel, JSPM, you name it), with a friend, specifically how we should structure his application in order to have a smooth migration to Angular 2 when time comes.
I had an application that heavily relied on the principles outlined by John Papa’s Angular Style Guide, but was also using Redux (a Flux-like state manager library), had some important modifications, conventions, and tools; and throughout this article we will be describing most of them, some of the concepts might be new to you, some might not, feedback is always welcome that’s why I encourage you to leave some on the comments section.
At this point, if you look closely, it should come as no surprise that my blog is now powered by Ghost, it’s also deployed inside a Docker container in a DigitalOcean droplet.
I’ve been thinking about my setup and how easy it was to get it running, I figured I might want to write about it. There are plenty of tutorials out there on how to deploy this blogging platform, but my configuration and hence this article it’s a little more advanced, since it attempts to cover areas many of those don’t.
The MVC architecture, today’s standard for at least web development, if abused, often turns into a nightmare of objects sharing a lot of responsibilities, and spanning across different areas, knowing about different objects, essentially defeating the holy grail purpose of separation of concerns.
We shouldn’t be polluting MVC, we should be embracing it. There’s a reason that monolithic have become a problem, and while I certainly favor micro-services and SOA for complex applications, I’m aware that usually the problem with them it’s not having everything under the same directory structure, it’s not the team, and it’s not isolating components, it’s usually the code inside that app that has become a burden to maintain and refactor.
It’s interesting that something as small as a badge is a good indicator of your project’s health, popularity and status; somewhat essential to improve visibility, and trust, no matter whether your project is open source or private, or is hosted on GitHub, BitBucket, GitLab, or a custom setup. It allows you (and your team) to have a place where you can instantly be aware of your project’s status, as well as your users (whether is the general public or management) to have small but interesting metrics on your project.
I’m self-aware that I have a love and hate relationship with blogging, and while I’ve tricked myself to be consequent during this new episode of it, the one you’re reading, I can’t help but thinking that my blog posts will go the usual route given the platform is running is called Ghost ;)
That usual route was insane periods of inactivity, something I’ve reflected upon, and trained myself on how to avoid, time will tell how that goes, I’m confident it’ll be good and I won’t have to do another post like this 3 years from now, or not because I had to import stone age-old posts, at the very least.
JWT (short for JSON Web Token) is a compact URL-safe means of representing claims to be transferred between two parties, as defined by the standard. It’s usually used for authentication and recently is being favored over the classic cookie scheme in Single Page Applications (SPAs).
Although cookies and server-side authentication are the most established solutions, for APIs usually better alternatives are OAuth2 and JWT.
This post assumes some level of familiarity, but should be easy to follow, visiting the homepage that I linked before should suffice for most of the code samples, if you want me to do a resources recommendation to dig deeper you can check Intridea’s blog post, another one by Toptal (it’s focused on Laravel, but the introductory section it’s worth reading), or if you want to go all the way you check this PluralSight course on OAuth2, OpenID Connect and JWT.
Every now and then, I stumble upon some post that raises interesting questions worth to be answered or commented upon, hence the “My Answers to…” series.
This one in particular is worth the name since they’re explicitly relating to interview questions, which were formulated in a very interesting blog post follow-up by Sohan back in 2010.
Questions 1. What is Rack Rack is a web server interface for Ruby frameworks. It provides a common interface and middleware to provide a common HTTP-to-application-server communication layer regardless of the backend server implementation.