Software “Micro”

I think we’re all sold on the idea of microservices; they reduce risk, improve maintainability, and reduce fragility.

When you think about it, everything in the Software Development Life Cycle (SDLC) is all about reducing down to the small possible increment. With user stories & requirements we want to boil down to a very small, defined, specific action. We then write it out, pass it over to a developer who builds it, then test the small, specific action to confirm done.

The same is true and applies to classes and functions. Back in the old days some PHP devs (never me) would build “grand unified classes”; a single, massive class with too many disorganized functions to do everything under the sun. This was immediately identified as bad practice and discouraged. But, we still face that issue on a smaller scale. Some developers (sometime me) will write a “login class” and have functions for “check email”, “valid password”, “write session”, etc. Just like user stores & requirements, a class should do 1 thing and do it well.

We’re starting to see the “micro thought process” applied to the front-end. We see this in React/Angular/VueJS components that do 1 thing well and can be reused throughout the application. But, all these components end up pulled together into 1 massive front-end project; PWAs (progressive web apps) and SPAs (single page apps).

What I have done on a project I’m just wrapping up is to build multiple, micro-UIs. These are React apps and they have many shared components and modules (through Git submodules and symlinks). So for example, I have mciro-UIs for:

• /login
• /home
• /account
• /post
• /administration

Organizing the project in this way only the specific JS & components for login are downloaded when the user wishes to login. A well organized PWA will do this too but it requires dedicated work to achieve. After login, the user is redirected to /home but because only a small JS file is required for the specific, dedicated home functionality the redirect is extremely fast. Each one of these micro-UIs, being a standalone project, confirm the user is logged in (except /login obviously) and has permission to access the given functionality. I could, in theory, have a front-end developer working on /home and another developer working on /account in parallel.

Microservices are [typically] a new, separate HTTP call to localhost or another server on the same network. Each microservice runs as a separate, small application with some shared code resources and by doing so the application is decoupled, simplified, and allows many developers working in parallel. I would argue the same approach can easily apply to micr-UIs where each is a complete, stand-alone application with some shared code resources.

There are many ways to share the overall HTML template and ensure a consistent look & feel. The way I’ve chosen to do this is have a single html.inc.php file containing html->header(), html->footer, html->menu(), etc. Every micro-UI uses essentially the same index.php file and calls the same shared HTML file. This also then leverages the browser cache and pulls some simple, basic components out of the JS making it faster and easier to cache/load.

That’s a long, complex post for a simple concept; I hope it makes sense. The bottom line is, /login is a stand-alone web app, all it has to do is accept an email, password, and remember-me. It then sends that data to the API to validate/authenticate/authorize. Assuming success, it then redirects the user to the next UI (in my case next_url is provided by the API). /login doesn’t know or care what the next URL is or what it’ll do because /login is concerned with 1 thing only.

How decoupled is our front-end?

Can you think of applications that are or are-not decoupled?