When I started my study about JWT, I was searching for a smart method to authenticate a request, without querying the database each time to check the applicant reliability.
I needed a token or something similar with the ability to validate itself and flexible enough to customize the validation strategy.
Imagine for example a web application where a user can login and obtain a “pass” with his name and an expiration time, and this pass will let him ask for resources until the pass expires, and only if the issuer is trusted.
Thanks to JWT’s self verification capabilities, I could discard every request where the token is invalid (a fake token not signed by my application) or expired.
Beyond this specific use case, JWT can be also useful to securely transmit data to other applications.
Last time we looked at the Signal class, that is, a simple, reusable way of encapsulating the observer pattern. There are many use cases for a signal, and I’m going to show one possible application, spawned from a real-world problem. View controllers’ composition and decoupling is hard: we often need an input from a view controller, that has to send its input back to its creator, while handling the back navigation somehow. We often find ourselves in a situation in which several different responsibilities are all expressed in a single view controller, with the effect of creating a gigantic class, full of entangled imperative statements, hard-to-understand sequencing and general complexity. We’ll use the Signal class to assign the various responsibilities to different classes, and write cleaner, more declarative code. The core of this architectural pattern lies in inverting the way in which objects communicate, view controller or other: instead of asking objects to do things, we’re going to observe what objects are doing, and react accordingly. Observe and React are the cornerstones of the programming paradigm known as functional reactive programming(FRP); the present article is not going to talk about FRP as a whole, nor to present shared FRP techniques; the point is to discuss an architectural pattern for decoupling view controllers from responsibilities not strictly related to user interaction, by leveraging some basic FRP tools.
The lesson we learned with REST
For many developers, nowadays, building an API for their applications essentially means mapping the resources of the domain to URIs, with the REST principles in mind.
Usually creating a RESTful system is not difficult, and the simplicity of the idea makes the task easier.
Let’s see some of the consequences and benefits of choosing REST:
- Every HTTP verb has its own meaning, allowing the developer to understand immediately what kind of operation (typically among the CRUD ones) is going to be performed on the resource identified by the URI.
- Often the same URI can be used with multiple verbs to accomplish different tasks (e.g. “example.com/tag/123” refers to a particular tag that you can retrieve, update or delete).
- Controllers in many server-side frameworks can be created with a RESTful approach, each one of them representing one or more resources.
However, unfortunately, it’s often easy to come across some problems:
During the past year I experimented a lot with file systems in Userspace using FUSE, I wrote this post to share my thoughts about what I did and to give you a starting point to do something by yourself.
Introduction
A filesystem is that piece of software that is in charge of storing, organizing and generally taking care of data represented as files and directories.
If you are using a device to read this post you are probably using at least one filesystem at the moment.
Composer e l’ecosistema PHP
L’ecosistema PHP è notevolmente cambiato negli ultimi anni grazie all’introduzione di Composer.
Esso ha definito degli standard per risolvere problemi comuni come l’autoloading e la gestione di pacchetti e dipendenze.
In questi ultimi anni si è assistito ad un proliferare di numerose componenti software riusabili che hanno significativamente modificato le strategie di sviluppo.
Nonostante Composer si sia evoluto molto, in alcuni contesti le sue funzionalità risultano essere limitanti e incomplete.
I framework e i pacchetti più complessi hanno bisogno di una gestione personalizzata delle dipendenze. Generalmente sono necessarie operazioni di configurazione e registrazione. Ciò è specialmente vero per pacchetti core dei framework come i template engines.
Composer, inoltre, possiede una cattiva gestione delle risorse non PHP. I file di configurazione devono essere gestiti manualmente oppure è necessario adottare standard strettamente legati a ciascun framework.
