Forem: Oskar

[Unpopular Opinion] React is heading in a wrong direction (old)

Oskar — Fri, 27 Jan 2023 20:46:46 +0000

How did we get here - a short history of frameworks

I've built SPA applications with JavaScript before front-end frameworks (angular.js) came about.

Those days SPAs were jQuery-heavy piles of software engineering "inventions" glued together by scripts and closure-based namespaces - the early ancestors or modern modules.

Since everything was custom-made by "the senior dev", there was no documentation and little of the original idea was transmitted to juniors without a serious disturbance.

Angular.js

That was the context in which Angular.js came about.
It offered a good documentation, interesting concepts and clear-cut separation of responsibility between them (except the difference between the service and provider which was arguably the most famous angular interview question).

But Angular.js was built yet in the now-legacy "pages-mindset" following initial ideas around HTML and CSS.
While it was fine for some time, as Web 2.0 started to kick-off with rich experiences where focus shifted even more (from information sharing) towards user indulgence - UX became mission-critical.

React.js

And React was the one that offered a new way of keeping websites more consistent by shifting the paradigm from pages mindset to component composition.

Now websites were not only ~~built~~ composed from self-contained, reusable blocks like the Lego (CSS needed a while to catch up) but it was also less opinionated than Angular.js when it comes to the front-end architecture and especially state management.
"React is the 'V(iew)' in the MVC" - was the main catch phrase those days.

MVC roots of the front-end frameworks and React as "the V"

We must remember that those were times when rich front-ends were primarily built by re-specialized PHP developers coming from Symphony / Cake PHP Frameworks background - therefore MVC was a natural structural design pattern for them (and that for long influenced the front-end frameworks).

But since React was "the V", then what about the Model and Controller? What about the logic and communication?

Here we come to the central problem since the dawn of React.

The problem - React's attempts to "do more"

The first approach React took towards the State Management sounded awesome (and trivial) - let's just pass the whole state from the root component to its individual leaves via props - propagating it through all components in-the-middle like a waterfall.
And boy... it worked so beautifully. At least for the simple examples in documentation.

But since real front-end application were much larger, as a developer those days you could witness 10-30 different props shared from the App through the whole React tree just to hit their leaf components.
Official solution? Just share them via ...props syntax.

But typing ...props reduced visibility (of which props actually are passed down) leading to many errors and overall... it was just a hack.

Flux Architecture and Redux

So Flux architecture with the concept of Stores, Dispatchers, and Actions came about (from React team), and then Redux (a simplified version of Flux - for juniors by a junior).

Flux was better than Redux but a great documentation (including first-and-foremost a complete, free video tutorial on egghead.io), simplicity of having a single Store, and some "toys for boys" (Redux DevTools with "time-travelling") won developers over and started Dan Abramov's (inexperienced, yet very charismatic 19-years-old freelancer) career in Facebook's React core team.

So, with everyone having their hands on Redux, Flux architecture being completely forgotten (or even never discovered) all we needed to do to have a complete, easy, flexible, and universal solution for front-end development was to incrementally move out from Redux back to Flux with some default bootstrap that would enable junior devs start small quickly and a guide on best practices how to scale.

Mobx - final solution?

All we needed was something like... Mobx - way less verbose, more flexible and without forcing everyone to write immutable code (regardless what is our opinion about mutations, it's not something that should prevent a library from working).

And there was the time that developers started to notice it. As their projects were getting bloated by thousands of Redux reducers glued together into a single Super-Store and they hit its limitations coming from over-constrained architecture, more people started to switch to Mobx and build some high-quality, highly-maintainable, yet concise and elegant architectures.
It enabled developers to have a clear separation of concerns, stateless, functional components, and organized way of keeping their logic in shape.

Context API

React tried to design its own, scalable way of managing state and released the first version of the now-legacy Context API (but it didn't get much traction) and then (in React v16.3) another (current) version.

Just look at the syntax to reuse state of two objects in the component (which contains a single line of real code and 10 lines of boilerplate to enable state reuse):

import ThemeContext from '../../../Context/ThemeContext';
import UserContext from '../../../Context/UserContext';

<ThemeContext.Consumer>
   {theme => (
     <UserContext.Consumer>
       {user => (
         <ProfilePage user={user} theme={theme} />
       )}
     </UserContext.Consumer>
   )}
</ThemeContext.Consumer>

So React team had a problem now.
For some reason, they didn't wanted to keep React doing what it was designed to do (and what it does very well) - being the "V" in the MVC.
They wanted to take over State Management.

But they had this ass-ugly Context API loaded with Render-Props boilerplate just to make it work.
And it was so bad, it was so against React's own goal of component reuse, that in the same documentation page describing the Context:

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

They had to add a disclaimer saying:

Apply it sparingly because it makes component reuse more difficult. If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.

Which essentially says - here is the solution for the problem of passing props via multiple layers, yada, yada, yada, but you shouldn't use it only if you want to solve the problem of passing props via multiple layers. Use it only when you are desperate and on your own risk (you were warned).

Hooks

So to fix the syntax problem the React v16.6 came about.
With hooks.
A minor feature with major consequences.
Over-hype that could be beaten only by Cyberpunk2077, Luna and NFTs.

But it was a game changer when it comes to adoption.
When React team said that Hooks solve the issue with clutter of render props and HOCs around the code - they meant mainly the problems caused by their Context API (the other reason was to get rid of the classes to reduce the effort of maintaining two ways of achieving the same thing - which is totally understandable).
And it does make the syntax cleaner.

Yet the problem persists:
React team keeps trying to solve problems that are already solved much better by others (Mobx is just one of them) instead of focusing on what was the mission which let React to capture hearts of millions of developers in the first place - the efficient, declarative management of DOM.

I do not claim that React doesn't do its primary objective right (I think it does), but by pushing its own inferior solutions for State Management instead of collaborating with better solutions available in the open-source to refine them for the whole range of use cases, they are just creating chaos both in juniors' minds and during interviews.

I'm happy to listen to your opinion and I do care about it so regardless if you agree or not, please share it.

Thanks for reading.

Reviewing popular NPM packages

Oskar — Fri, 01 Nov 2019 21:41:41 +0000

Reviewing popular open source packages

Do you know any websites, that review popular open source packages?

If not, would you like to join me doing it?

My proposition of review template:

Informative part

1) The problem, that the npm package solves
2) Abstract description of techniques used to solve the problem
3) Alternative approaches, that could be possibly taken

Results part

1) TESTS - Test coverage for the logic.
2) CLEAN - Size of the functions, naming conventions, files structure, separation of concerns.
3) CRAFT - Single responsibility, Open-Closed, YAGNI, DRY.

I think with the amount of NPM packages we use in daily basis, our power would improve significantly if we could better understand them and incentive authors to keep the highest quality.

Let me know your thoughts.

Serverless with real-time communication (WebSockets)

Oskar — Wed, 07 Aug 2019 17:43:26 +0000

Disclaimer

This article is a deep dive guide to build WebSockets on Serverless architecture.

If you are not familiar with WebSockets, please first What are WebSockets?
If you never used Serverless, please read first What is Serverless?

Introduction

Last year my team built 100% serverless mobile application which now helps hundreds of developers to maintain happy and healthy teams.

Check how the Team Health Check help developers

Tools, that help me build healthy 💕 and performing teams 👩🏾‍💻👨🏼‍💻

Oskar ・ Jun 1 '19

#team #career #performance #webdev

After we've built the first version of the app, something felt off.
Imagine the app, where each screen must call the Lambda function to get the data every time, and if someone joins your team, you must navigate out and in again to see the change.

We've realized, it's time for a real-time connection.

We've tried easier way (AppSync), and... more flexible way :) (API Gateway v.2). This guide presents the more sophisticated architecture - using API Gateway.

Difference between Serverless REST API and Serverless WebSockets.

Let's first review how typical serverless architecture looks like, and then see how it evolves when we add the sockets layer.

Serverless using REST API

Handling REST API requests on Serverless is a straightforward process, which in the most common case utilizes 4 layers - each responsible for its own functionality (diagram below).

User sends a request with Authorization header to the API Gateway.
API Gateway authenticates the user with out-of-the-box Cognito User Pool authorizer. Amazon Cognito grants (or denies) the access, and pass the user attributes as uuid or email to the request context.
API Gateway executes the associated Lambda function together with the user attributes.
Lambda function makes all necessary requests to a database, data transformations and returns a response to the API Gateway
API Gateway pass the response back to the user.

The same process, including authentication, happens every single time, for every request.

Easy, right?

WebSockets on Serverless

WebSocket connection though, is more… sophisticated :)

The user here is authenticated only once - during their initial UPGRADE request. If authentication process succeed, then the socket connection is established for as long, as any of the sides doesn’t close it.

User making subsequent requests to the WebSocket protocol doesn’t provide his claims because connection is stateful, and the server (here API Gateway) keeps the information about the sender.

The below diagram presents what happen when devices connect to the API Gateway WebSocket API, and later when one of the users invoke the API (in this case the user is voting, and his teammates get notified about it).

There are a few interesting facts about this architecture.

We are implementing Custom Authorizer.

API Gateway WebSocket API doesn’t offer out-of-the-box integration with Cognito User Pool. Therefore a Custom Authorizer must be implemented by ourselves.

The Custom Authorizer is a Lambda function, that validates JSON token with a public rsa key fetched from an authorization server where the user exist, and later grant the access by a setting a proper IAM policy in the response.

We are storing socket id for later reference.

When the access is granted, it’s our responsibility to save the socket id to the database such as DynamoDB.

In the above architecture the socket id is saved both to ConnectionsTable and ProfilesTable.

Authorizer is executed only once.

Both Authorizer and onConnect are the lambda functions executed only once when user connects to the socket API. This makes the subsequent requests to the socket even faster.

We can call the socket from anywhere, even outside AWS.

We can notify the socket from another service such as Lambda Function, EC2 or even outside AWS.

We do it by sending a POST request to the API Gateway's @connections route with id of a socket we want to notify in the path.
If we want to notify 100 sockets, we must send 100 POST requests what can be a bit worrying, but so far it worked well in our production app.

We are signing every request.

Each request to the API Gateway WebSocket API must be signed. This is to ensure API Gateway, that we have a permission to push a data to the user through the socket.

Not long ago it required a lot of steps, but thanks to our recently released npm package aws-request-signer you can do it with almost no effort.

To wrap up

We've covered the typical serverless architecture, then we've shown how it evolves when we add real-time communication and lastly we've covered some of the most interesting highlights about it.

If you want to go serverless, or need to add real-time communication, feel free to text me, or hire my services so you can enjoy fully automated serverless setup with the best practices within a week.

If you don't agree with any part, please comment your feedback.
Follow if you don't want to miss more deep dive content from production apps.

Thanks for reading!

Tools, that help me build healthy 💕 and performing teams 👩🏾‍💻👨🏼‍💻

Oskar — Sat, 01 Jun 2019 13:28:41 +0000

If you were assigned to building a company's dream team tomorrow, what techniques and tools would you use to support your strategy?

Building a top-performing team

Great teams don't born within a single day. Every team must go through certain stages before it can eventually become a company team no. 1. You know... this kind of team, that you ask for help when things get really serious - Special Forces, Aces, Alpha Dogs... call them whateva.

But what are those stages, and why not every team reach this top-performing state?

Stages of group development

The scientist Bruce Tuckman is proving in his popular theory the Tuckman’s stages of group development, that to reach high-performance state, every team goes through three preceding phases - forming, storming and norming.

Then is walking through those phases to performing state just a matter of time?

Yeah... my ass.

During those phases basically everything can go south. And it often does.
From the power fight during the storming phase (have you ever been in a team built from former technical leaders? You gonna love it), to building dysfunctional norms like finger-pointing or never saying no to your boss (and then leaving your team with it).

It seems like most of the teams don't spend enough time building the foundations, which would enable them to be something more than just a group of people working together.

Why is that?

Sh## must be delivered

Usually, teams are created with a single purpose. To deliver a particular task. The task becomes their top priority and progress towards it (or lack of it) is the main measure of their success. Therefore it’s not surprising managers create all sorts of incentives pushing teams to the limits regardless of their health.

Unfortunately, that push for results without a solid understanding of the team health — the same as driving a car without reviews nor repairs — leads (in the best scenario) to the permanent damage.

How to avoid the damage?

Let me share some techniques, and tools, that help me build healthy and performing teams in a consistent, and repeatable way. By doing it you will gain the highest value - trust and loyalty of your folks - in return.

Team Health Check

If you are a part of a development team, this tool is just for you.
Team Health Check is a mobile app based on retrospectives model designed by Spotify.

No app can replace honest conversation between the team members, while everyone has a say about their feelings and thoughts.
But how to understand the key pain points of your team without getting bragged into long, negative spirals of complaint with no certainty if the identified issues are addressing a real threat or just demands of the most vocal part of a group?

Team Health Check addresses this challenge by involving the whole team in anonymous voting for the most important (and urgent) parts of its work.

Learning	Delivering value

Predefined categories enable your team to start immediately.
Register the free account in the iOS or Android app, and you are ready for your first health check!

Then just keep an eye (and swiftly improve) on the direction of your team by looking at the trend between multiple health checks/votings.

How to download?

Since Team Health Check is a mobile app, you can find it in the App Store or Google Play or by scanning the below QR.

iOS	Android

Stickies.io

If you already know the health of your team (you can use Team Health Check for that), then quick brainwriting session is likely what you are looking for next.

Brainwriting is a technique similar to brainstorming, but the participants fill their ideas on sticky notes.

What is cool about brainwriting is:

It’s very democratic — All your folks can write in the same time and express their opinion without competing for attention.
It promotes non-conformism — While during brainstorming people can gravity around previously expressed idea, brainwriting let everyone to focus just on their thoughts.
No social loafing — Teams have a tendency for a minority of people to do a majority of the team’s work, while some people don’t contribute. Brainwriting addresses that by giving an equal chance to contribute to everyone and making the involvement more transparent.

Stickies.io is a free, virtual sticky notes board. The website enables to organize brainwriting session even for distributed teams, while (optional) incognito mode ensures participants can focus on their own ideas (without seeing each other's notes).

After the session, participants can uncover their ideas, group them together, and vote for the best.

What next?

Building teams is a time-consuming process that can’t be done once and forgotten.

I’ve shared with you my favorite tools, that help me build healthier teams.
They can be also your compass and guide your team on a challenging road to find its own, individual culture fitted to its own, unique context.