DEV Community: Olawale Bashiru

How I Bridged AWS Face Liveness to Expo with a Native Module

Olawale Bashiru — Thu, 04 Jun 2026 16:29:16 +0000

AWS Face Liveness has native SDKs for iOS and Android.

That works well if you are building fully native apps.

But if your team is building with Expo, the integration path is not as simple as installing a JavaScript package.

You still have to think about native iOS setup, native Android setup, camera permissions, Amplify configuration, credential handling, build configuration, and the bridge between JavaScript and native code.

That gap is what led me to build expo-face-liveness-for-aws-amplify, an Expo module that integrates AWS Amplify Face Liveness into Android and iOS Expo projects.

The business case was clear too: financial and identity-sensitive products often need to verify that a real person is completing sensitive flows like onboarding, KYC, account recovery, fraud prevention, or high-risk actions.

Face liveness does not replace every other security measure. It adds another layer of confidence that the product backend can use as part of its final decision.

This article breaks down how I approached the problem, what AWS Face Liveness needs architecturally, how the module is designed, the tradeoffs I made, and what I learned from the first release.

Here is the module running on both platforms:

iOS	Android

Why this problem exists

For fully native mobile apps, the integration path is more direct.

You install the native SDK, configure the platform-specific requirements, and render the UI component provided by the SDK.

For Expo teams, the story is different.

A React Native or Expo app may share most of its product code across platforms, but native SDKs still require platform-specific setup.

That means:

iOS configuration
Android configuration
camera permissions
native dependencies
version compatibility
build configuration
credential handling
JavaScript-to-native events

Before abstracting this into a package, the painful part was not only getting the detector to render once.

The painful part was knowing that every product with the same requirement would have to repeat the same native setup decisions: how to configure iOS, how to wire Android, how to handle camera permissions, how to make Amplify credentials available, how to expose native completion events, and how to keep the backend as the source of truth.

That repetition was the real signal.

Once the same liveness requirement appeared across multiple products, including one I was leading and another a colleague reached out about, the problem stopped being “how do I make this work here?” and became “how do I make this easier to reuse anywhere an Expo app needs it?”

What AWS Face Liveness needs to work

Before building the module, I needed to understand what the SDK actually requires.

AWS Face Liveness is not just a screen you open in the app. It depends on a few moving parts working together.

The first part is authorization.

The liveness detector needs the app to be configured in a way that allows the SDK to communicate with AWS during the capture flow. In the standard Amplify setup, this is usually handled through Amplify Auth and Cognito-backed resources.

The second part is the liveness session.

A session is created by the backend before the client starts the liveness flow. That session acts like a reference shared between the backend, the client app, the AWS service, and the Face Liveness SDK.

At a high level, the flow looks like this:

Backend creates a Face Liveness session
App receives the session ID and region
App renders the Face Liveness detector
Native SDK performs the liveness flow
App receives a completion event
Backend verifies the final result

The important design principle is this:

The mobile app participates in the flow, but it should not own the trust boundary.

The backend should create the session and verify the final result. The client should only receive what it needs to start the liveness experience.

Why I chose runtime credentials

One of the most important design decisions was how the module should receive AWS credentials.

The standard Amplify/Cognito-oriented path works well when an application already uses Amplify Auth and Cognito-backed configuration.

In that setup, the app is usually initialized with generated Amplify client configuration, such as amplify_outputs.json or amplifyconfiguration.json, depending on the platform, SDK version, and setup path.

That configuration tells the Amplify client libraries which backend Auth resources to use, including details such as the AWS region, User Pool, User Pool Client, and Identity Pool.

The native app also needs the relevant Amplify Auth plugin setup so the SDK can resolve AWS credentials for service calls.

That is a good fit for apps already built around Amplify and Cognito.

For a reusable Expo module, though, I did not want to force every consuming app into that structure.

Some apps may already use Cognito. Some may use a different authentication system. Some may want their backend to own the full credential flow. Some may need to support multiple environments or products where credentials are resolved dynamically instead of being tied only to a generated Amplify client configuration file.

If the module assumed one Amplify/Cognito setup, it would become less reusable.

So I chose a runtime credentials path.

Instead of coupling the package to a specific Amplify Auth configuration file or Cognito setup, the host app can fetch temporary credentials from its backend and pass them into the module before rendering the detector.

In this package, that happens through setAuthCredentials.

Internally, the native layer provides those credentials to the AWS Face Liveness SDK through a custom credentials provider.

This keeps the boundary clear: the host app owns its backend and authentication model, the backend issues temporary scoped credentials, and the module focuses on the native Face Liveness integration.

Module architecture

The module is designed around a simple idea:

Keep the host application responsible for trust, and keep the package responsible for the native liveness experience.

To make that work, the package is split into a few layers.

Layer	Responsibility
Backend	Creates the liveness session, issues temporary credentials, and verifies the result
JavaScript API	Exposes methods for setting and clearing credentials, and a detector view for the app to render
Credential store	Holds temporary credentials until they are needed by the native SDK
Custom credentials provider	Reads from the credential store and provides credentials to AWS Amplify
Expo config plugin	Prepares native project configuration during prebuild
iOS native layer	Renders the AWS Face Liveness detector on iOS
Android native layer	Renders the AWS Face Liveness detector on Android
Event bridge	Sends completion and error events from native code back to JavaScript

The credential store and custom credentials provider are separate on purpose.

The store is responsible for holding the latest credentials passed from JavaScript. The provider is responsible for giving those credentials to the native AWS SDK when it asks for them.

This structure keeps the package focused.

It does not try to own the backend. It does not decide how the consuming app authenticates users. It only provides the bridge needed for an Expo app to use the native Face Liveness experience on iOS and Android.

Public API design

I wanted the JavaScript-facing API to stay small, explicit, and easy to reason about.

The package exposes a few core pieces:

setAuthCredentials
clearAuthCredentials
FaceLivenessDetectorView
onAnalysisComplete
onError

The intended flow is simple:

Set credentials. Render the detector. Listen for completion. Verify the result on the backend.

setAuthCredentials gives the native layer the temporary credentials needed to run the liveness flow.

clearAuthCredentials lets the host app intentionally remove credentials when they are no longer needed.

FaceLivenessDetectorView is the native UI entry point in the React Native tree.

onAnalysisComplete tells the app when the capture flow has completed.

onError gives the app a way to handle failures from the native layer.

Config plugin design

For Expo projects, a package is not complete if developers still have to manually patch native files every time they run prebuild.

That is why the config plugin is an important part of the package.

The plugin helps prepare the native project configuration needed by the module, including:

camera permissions
Android desugaring
Android Compose compiler setup
native configuration required by the underlying implementation

If every consuming project has to manually rediscover the same native setup steps after prebuild, the abstraction is incomplete.

The config plugin moves those repeatable setup details closer to the package, so the consuming app can focus on the product flow.

Security and trust boundary

One of the easiest mistakes in mobile integrations is placing too much trust in the client.

For this package, I wanted the boundary to stay clear: the mobile app can start and display the liveness flow, but the backend should create the session, issue temporary credentials, and verify the final result.

Long-lived AWS credentials should not be bundled into the mobile app. Anything shipped inside a mobile app should be treated as visible eventually.

That separation keeps the mobile client as a participant in the experience, while the backend remains responsible for trust decisions.

Key decisions and tradeoffs

Decision	Why it mattered
Build as an Expo module	The target users are Expo teams that need native SDK integration without abandoning their Expo workflow.
Support iOS and Android	AWS Face Liveness is distributed through native mobile experiences, so both platforms needed first-class support.
Use runtime temporary credentials	It keeps the module reusable across apps with different backend and auth setups.
Keep result verification on the backend	The backend should remain the source of truth for sensitive verification decisions.
Add a config plugin	It reduces repeated native setup work across consuming Expo projects.
Add unsupported web entry points	Unsupported platforms should fail clearly instead of silently behaving in unexpected ways.
Start with a focused API	A smaller API is easier to document, test, reason about, and improve based on real feedback.

There are also important limitations.

The package does not work in Expo Go because it includes native iOS and Android code. It requires a custom development client or a native/EAS build.

Web is also not supported. The package is focused on the native mobile Face Liveness experience.

The consuming app still needs a backend flow. The package does not create liveness sessions or verify final results by itself. That responsibility should remain on the backend.

Not every customization option from the underlying native SDKs is exposed yet. The first release focuses on the core liveness flow.

Finally, native SDK compatibility still matters. Since the package depends on native AWS Amplify SDKs, future changes in Expo, React Native, Android, iOS, or AWS dependencies may require compatibility work.

How to use the package

To try the package, install it from npm:

npm install expo-face-liveness-for-aws-amplify

Add the config plugin to your Expo config:

{
  "expo": {
    "plugins": [
      "expo-face-liveness-for-aws-amplify"
    ]
  }
}

At a high level, the app flow looks like this:

import {
  FaceLivenessDetectorView,
  setAuthCredentials,
} from "expo-face-liveness-for-aws-amplify";

await setAuthCredentials({
  accessKeyId,
  secretAccessKey,
  sessionToken,
  expiration,
});

<FaceLivenessDetectorView
  sessionId={sessionId}
  region="us-east-1"
  onAnalysisComplete={() => {
    // Ask your backend to verify the result.
  }}
  onError={(event) => {
    // Handle native SDK or configuration errors.
  }}
/>;

expiration should match the format expected by the package API for temporary credential expiration. In your implementation, document whether this should be an ISO string, timestamp, or JavaScript Date value so users do not have to guess.

For full setup instructions, backend requirements, and troubleshooting, see the GitHub documentation.

GitHub: https://github.com/olawalethefirst/expo-face-liveness-for-aws-amplify
npm: https://www.npmjs.com/package/expo-face-liveness-for-aws-amplify

Gotchas to know before using it

There are a few important things to know before trying the package.

First, it will not work in Expo Go. The package includes native iOS and Android code, so you need a custom development client or a native/EAS build.

Second, the app still needs a backend. The package does not create Face Liveness sessions or verify the final result. It only handles the native mobile liveness experience.

Third, credentials must be available before the detector is rendered. In this package, that means calling setAuthCredentials before mounting FaceLivenessDetectorView.

Fourth, native SDK compatibility still matters. Since the package depends on the underlying AWS Amplify native SDKs, changes across Expo, React Native, iOS, Android, or AWS dependencies may require compatibility updates.

Lessons learned

A few lessons stood out while building this.

First, native SDK integration is rarely just about rendering a native view. Build configuration, permissions, credentials, platform differences, and backend responsibilities all matter.

Second, reusable infrastructure often starts from repeated product pain. A one-off solution may be enough the first time. When the same requirement appears across multiple products, abstraction becomes more valuable.

Third, identity-sensitive flows need clear trust boundaries. The mobile app can provide the experience, but the backend should own session creation, credential issuance, and result verification.

Roadmap

The first release focuses on the core Face Liveness flow for Expo projects on iOS and Android.

Next, I want to improve the package around the areas that make real integrations easier: clearer backend examples, better example app coverage, broader Expo SDK compatibility testing, CI checks for native builds, and clearer documentation around native SDK customization boundaries.

The goal is to keep the roadmap practical and shaped by real usage feedback, not to make the package own every part of the liveness experience.

Conclusion

This package started from a product integration problem.

At first, the goal was to help a team move forward without rewriting an application. But as the same need appeared across more products, the problem became bigger than one implementation.

That is what led me to build expo-face-liveness-for-aws-amplify.

For me, the most valuable part was not only getting the native SDKs to work. It was designing the boundary between business need, backend trust, native implementation, and developer experience.

That is the kind of engineering I enjoy most: turning repeated product needs into infrastructure other teams can build on.

Hey guys, breakpoint-overlay crossed a 100 GitHub stars milestone! Read about it if you've not yet.

Olawale Bashiru — Mon, 24 Nov 2025 19:49:37 +0000

Olawale Bashiru

Nov 12 '25

How I Built a Tiny Tool That Makes Responsive Design Feel Effortless

#frontend #javascript #css #opensource

109

Comments 35

5 min read

[Boost]

Olawale Bashiru — Sat, 22 Nov 2025 13:20:32 +0000

How I Built a Tiny Tool That Makes Responsive Design Feel Effortless

Olawale Bashiru ・ Nov 12

#frontend #javascript #css #opensource

This is such an insightful POV

Olawale Bashiru — Sat, 15 Nov 2025 12:14:11 +0000

Sylwia Laskowska

Nov 5 '25

jQuery Will Outlive Half of Today’s JavaScript Frameworks - Here's Why

#discuss #webdev #javascript #programming

135

Comments 115

4 min read

52 GitHub stars and 12 daily npm downloads feel very satisfying. The feedback so far indicates that front-end developers find this tool I worked on important. If you've not read this publication yet, please do. I explained "why" I chose to work on this

Olawale Bashiru — Sat, 15 Nov 2025 12:01:26 +0000

Olawale Bashiru

Nov 12 '25

How I Built a Tiny Tool That Makes Responsive Design Feel Effortless

#frontend #javascript #css #opensource

109

Comments 35

5 min read

Hey guys, just in case you missed this: I documented my experience building an open-source solution to improving the experience of front-end developers. Please check it out!

Olawale Bashiru — Fri, 14 Nov 2025 08:10:34 +0000

Olawale Bashiru

Nov 12 '25

How I Built a Tiny Tool That Makes Responsive Design Feel Effortless

#frontend #javascript #css #opensource

109

Comments 35

5 min read

How I Built a Tiny Tool That Makes Responsive Design Feel Effortless

Olawale Bashiru — Wed, 12 Nov 2025 10:04:53 +0000

Setting the Stage

Ever wondered why the features your favorite product promises often take longer than planned? Or why it sometimes feels like engineers deliver more promises than features? Considering how disappointing it feels, experiencing both sides of that letdown has taught me how crucial it is to deliver on time and with high quality.
Developer tooling is one of the core elements that impact delivery speed. The capacity of a developer is enhanced by great tools, such as the many hands of modern AI-powered workflows that enable us to accomplish more with less effort.

For frontend engineers, a core metric of their efficiency in replicating designs is how it looks on laptops, tablets, mobile devices, and large monitors: a phenomenon known as responsiveness. To achieve this, we define breakpoints: width thresholds that tell our layouts when to adapt.

Here's the catch, though: during implementation of a design, browser debugging tools don’t show which breakpoint is currently active. Developers have to cross-check window widths or manually inspect styles, a tiny task that makes each design review and QA cycle longer than necessary. This desire to maximize the efficiency of determining breakpoints sparked the inspiration to build Breakpoint Overlay: a small, yet effective widget that provides real-time responsiveness transparency.

From Frustration to Functionality

Once this gap was verified, I started looking for a way to increase productivity without interfering with my workflow. I wanted a tool that would be easy to use and integrate into my current workflow. Upon exploring existing options, it became clear that most required installing an entirely new browser just to work. That felt excessive. Switching tools comes with steep learning curves and uncertain trade-offs, so I aimed for minimal change and maximum impact.

That realization inspired me to build one myself, not just for me, but for others who care about speed, precision, and simplicity.
Once I had a clearer sense of how the tool should integrate, the next challenge was figuring out what it should feel like. I experimented with modal, sidebar, and persistent panel presentation models, but none of them felt light enough. I eventually settled on a badge overlay, a tiny, unobtrusive widget that quietly lives on top of your project without altering its flow.

The badge uses soft, muted colors to stay out of the way visually. In its collapsed state, it shows the active breakpoint, viewport size, and screen density. When expanded, it reveals a full list of user-defined breakpoints, a compact, focused display that respects the project’s aesthetic while delivering just enough information at a glance.

Once the design direction was set, I outlined functionality that would make it genuinely useful, not just visually informative. A small example is a keyboard shortcut to toggle the overlay’s imperative handlers, allowing developers to show or hide it instantly during workflow.

After settling on the idea and features, I turned my attention to the implementation specifics, which are what make a tool either a habit or a toy. In any setting, I wanted Breakpoint Overlay to be portable, dependable, and simple to use. A few guiding principles shaped this stage:

Core Concepts

Zero dependencies: Keeping it dependency-free ensures the widget stays lightweight and avoids conflicts within complex build chains.
Modularity: Each slice of implementation manages a distinct task, creating a unified system that is simple to test and expand.
Layered testing: To guarantee that its behavior continuously complies with design intent, each significant module has specific test coverage.

Key Technical Decisions

Resize Event vs. ResizeObserver: ResizeObserver does not alert users when the viewport height changes, despite being excellent for tracking content changes. To address this, I used a throttled window.resize handler, ensuring reliable breakpoint detection without performance loss.
Shadow DOM: Style and DOM leaks are common when multiple scripts share the same document tree. To avoid unintended collisions and maintain strict encapsulation, the widget renders inside its own Shadow DOM.
requestAnimationFrame: For smooth and efficient updates, the overlay throttles resize computations using requestAnimationFrame. Older updates are cancelled so the tool always reflects the most recent screen state, a simple but powerful performance win.

Each of these decisions reflects the same philosophy that started the project: efficiency through empathy, both for the developer’s workflow and the product’s integrity.

Reflections and Learnings

Charting unfamiliar territory always comes with unique challenges. Determining the minimum viable product (MVP) was a persistent problem for Breakpoint Overlay, just like similar projects.

The idea started simple: track the active breakpoint. But my curiosity got the better of me; I continued to experiment, adding other "cool-to-have" features, reporting container queries, and highlighting overflowing content. New user-experience choices, implementation specifics, and testing considerations arose with every addition. This pursuit for perfection can lead to an unending cycle of development, as was soon discovered.

Snapping out of that obsession was one of the most important lessons of the project. I discovered how to deliver a minimal version that addressed the correct issue first and to put impact ahead of complexity.

Beyond scoping features, there were challenges rooted in unfamiliar technologies. Setting up the project as a monorepo, a single repository managing multiple applications and their dependencies, was new to me. While leaving room for upcoming additions like documentation and integration examples, it was crucial for separating the widget's package, demo app, and configuration files.

These conflicting moments served as stepping stones. Every obstacle revealed a learning gap, and each gap led me back to documentation, community forums, AI research tools, and the open web—a reminder of how collaborative modern development really is.

Looking ahead, I envision Breakpoint Overlay evolving beyond its current functionality. Consider innovative adapters for popular design systems or a movable widget that can be positioned in any viewport corner. More than features, though, this project taught me that building well is about knowing what really matters and not just about adding more.

In the end, Breakpoint Overlay became more than a tool. It became a reflection of curiosity, restraint, and the constant pursuit of better ways to build.

Closing Thought

Every line of code in Breakpoint Overlay carries a lesson about design empathy, deliberate constraint, and the quiet power of developer tools.

Because sometimes, innovation isn’t about doing more; it’s about making what you already do feel effortless.

If you’ve ever wished for a simpler way to see which breakpoint your app is using, check out Breakpoint Overlay.

It’s open source, dependency-free, and available on both GitHub and npm. Feedback, suggestions, or contributions would be greatly appreciated, especially from engineers who share my passion for the developer experience.

Role of Cryptography in Secure Digital Communication and Software Development.

Olawale Bashiru — Sat, 20 May 2023 18:50:20 +0000

Ensuring safe digital communication may seem so simple at its core, yet can be the bane of a product's survival in the ever evolving market. This may seem like an overstatement, but when the risks are fully considered, it becomes apparent why so much money and effort is invested to evolve security practices and mitigate new risks as they are discovered. At the core of ensuring safe communication, lies one of the fundamental building block, Cryptography.

Cryptography can simply be defined as the practice of applying techniques to conduct secure data communication in the presence of adversaries. The key principle of cryptography is to ensure confidentiality, integrity and authenticity during communication.

TLDR: Cryptography is one of the core building blocks for secure communication in software development.

Core principles

Confidentiality: act of concealing data from unauthorised access.
Authenticity: ability to trace data identity back to its origin of creation.
Integrity: concept of determining if data has been altered since its creation.

Methodologies

There are several techniques upon which security of data is ensured, below is a brief summary of some of this concepts:

Hashing

This is a pattern of encoding data in cipher text such that the process is deterministic, irreversible, and collision resistant.
In simpler terms, this means that no data, plain text for example is redeemable from its encoded cipher text, making it an irreversible process.
Different cipher texts are formed for any slight change in the value of the plain text, hence deterministic.
Collision resistant refers to its ability to create a unique cipher value for every plain text hashed, ensuring that no two plain text have the same cipher text.

The cipher text, also known as hash is created by unique algorithms that are designed to operate by relying on specific mathematical theories. Examples of such theories are the discrete logarithmic problem and modular arithmetic.
One application of hashing can be illustrated in Public Key Cryptography, a pair of related key values that include a public and a private key. The public key is generated from the private through hashing.
By leveraging on cryptographic hashing, other important techniques have been designed, such as checksums and digital signatures.

Checksums

These are small values generated from the cryptographic hashing of specific data, typically much larger than the checksum itself.
The process of generating a checksum is a simple process, aimed at ascertaining the integrity of data during transmission or storage.
This is important because, some of the data may be accidentally misplaced or otherwise corrupted.
Its simplicity makes computing its integrity easy and efficient to ascertain.
It is typically used by data storage and transmission systems to enforce efficiency of the process.
Although they aren't a full proof solution to data security, they are useful for preserving data integrity.

Public Key Cryptography

This is an application of cryptographic hashing that consists of a Public Key, a Private Key and a Signature.
The public key is a value that serves as a means of public identity for its corresponding secrete private key.
Private keys are kept secret specifically for the power that it wields. Unauthorised access to a private key enables the possessor to impersonate the actual owner of the key.
By convention, private keys are generated from randomly generated data to maximise its security. Digitally, this randomness is simulated by relying on algorithms known as pseudorandom number generators.
Although private keys can be generated manually, this may compromise its security, hence advised against.
The private key can be used to form a binding relationship between the Public key pair and a signed piece of data, producing a corresponding signature.
Using the public key, the signed data, and the resulting signature, the authenticity of the signed data can be verified by any third party without accessing the private key.
This means that the signed piece of information can be verifiably proven to originate from the public key pair without the owner ever disclosing the private key, therefore establishing trust.
There are various types of digital signatures, each formed from by unique algorithms. Examples are the Elliptic curve digital signature(ECDSA) and Knorr signature.

Data Encryption

This is a cryptographic technique specifically aimed at enforcing confidentiality of data.
It is the process of encrypting or encoding data as cipher text such that it is confidential, reversible, yet difficult to decode by unauthorised adversaries.

This process is not aimed at preventing interference during transmission of data, rather it is designed to ensure intelligibility to any unauthorised interceptor.
This is achieved by using a secret key during the encoding of the data to secure it.
There are two forms of commonly used encryption techniques, Symmetric and Public-key encryption.
Symmetric encryption involves the use of the same key to encrypt and decrypt data, hence they’re easier to compute in comparison to Public-key encryption.
Public-Key encryption, also known as Asymmetric encryption, employs the use of a public key cryptography to encrypt data.
This is achieved by using a public key to encrypt data, such that only the bearer of its private key can decrypt it.
Because of this additional layer of separating concern, they offer more security, and as a result require more computing resource than symmetric encryption.
Ideally, data encryption does not guarantee full proof security from interceptors, but a well encrypted data will require a good amount of both skill and computational resource to decode without the required secret key.
Authorised decoding of encrypted text with the secret key on the other hand is as easy as cracking a nut, requiring relatively much lesser computational resource.

Practical Applications

Transport Layer Security (TLS)

This is a Cryptographic protocol that ensures security of transit data over networks.
It operates by providing end to end security of data sent between applications over the internet.
It leverages the cryptographic encryption of data during transit.
This encryption includes both Symmetric and Asymmetric types to maximise security.
A random session key is generated for the transmission session by the client.
It further uses the server's public key to encrypt it such that the server can only decrypt this session key using its private key, and transmits it to the server.
Upon receival and decryption of the session key by the server, both participants would bear the session key in their possession.
Further communication would then be encrypted and decrypted with the session key.
It is used in applications such as email, VOIP, instant messaging, DNS and web applications.

Data storage

The secure storage and transmission of data is one of the most important factors to consider when building software products.
A “minor” breach of data, either due to unauthorised access or accidental corruption can mar the reputation of any product.
The detriment of this risk is why software developers apply a combination of techniques to maximise security and ensure integrity.
An example is in the encryption of data during transit, between a client and its server, rather than leveraging only on network security. This additional measures further reinforces data protection.
Data hashing prior to storage is another means of storing extremely sensitive information, by reducing risk of exposure upon a breach. This pattern of storing hashes rather than actual data provides an elevated level of security to sensitive data. It is frequently applied in the storing of passwords and credit card information.
Lastly, Checksums are frequently used to establish the integrity of data at various point during its lifecycle.

JSON Web Token (JWT)

This is a mechanism designed to communicate authenticity of any entity, such as a user, by ascertaining their identity.
JWT is a standard for representing claims of ownership in modern applications.
It provides a secure alternative to storing login credentials such as username and passwords, on servers after initial authorisation, to verify future claims.
After the user's initial authorisation, a token is generated by the server.
This token is generated from the claim, such as a user’s credentials and an additional secret, known only to the server.
The token consists of three integral parts, namely an header, payload and signature.
The header contains the type of token created and the hashing algorithm used to create the signature.
The payload contains the claim, such as the identity of the user in this scenario.
While the signature is the cryptographic hashing of the header, payload and the secret data, known only to the server.
This token can then passed around back to the requesting client for use.
Whenever the client requires further access to any protected resource, alongside its request for the resource, it presents the previously received token for authentication.
Upon receiving this request, the server verifies the authenticity of the token, then grants access if successful.
JWT introduces better efficiency by removing a round trip, that would have been used by the server to authorise access requests with login credentials.

Decentralised systems

Thanks to recent boom in popularity of Bitcoin and decentralised systems in general, cryptography has gained massive popularity, prompting many to believe it is a recent innovation.
Decentralised systems are designed such that they rely heavily on the super powers of cryptography to function.
This results from the decentralised approach to authority in the system.
What this means simply is that unlike centralised systems which rely on a central authority for trust, to verify claims, or direct the affairs of the system, participants of most decentralised systems operate at the same level of control, with no participant ranking higher in authority than another.
This design to decentralise trust by distributing control, also prevents censorship of participation, promotes transparency, maximises both scalability and resillience of the system.

To enforce trust in a trustless system, cryptography is leveraged, from public key pair identities, to transactions integrity, authentication of claims, to network wide state consensus, creation of currency and much more.
The application of cryptography is evidently the glue that holds the several moving components of decentralised systems, operating efficiently as one.

Conclusion

I hope that with these few ramblings of mine, I have been able to successfully convince you and not confuse you of the importance of security in digital communication, the role of Cryptography and the need to ensure strict adherence to best security practices during software development.

Sources

Encryption
Cryptography Digital signatures
TLS Basics
JW Token
What Is JWT and Why Should You Use JWT
How Is Cryptography Used In Applications?

How my obsession drove me to re-engineer a different type of FlatList, I called it "NestedLists".

Olawale Bashiru — Thu, 20 Oct 2022 09:57:54 +0000

An exercise that started out as an effort to replicate a screen from one of the most used social media applications by leveraging on the React Native framework turned out to be a lot more work than I had originally anticipated. I assumed all I had to do was to slap a few React Native elements together with their appropriate styling and “Tada!”, I could applaud myself for a job well done. Little did I know of the impeding bottleneck patiently awaiting me.

Eager to complete the necessary work as quickly as I could, I dived right in to constructing a mental model of how the layout should be structured. This is my intuitive approach to implementing designs; I never go wrong with breaking complex designs into fundamental core components needed to achieve desired layout.

I concluded on an approach which required nesting FlatLists. In total, there were four of them.

One grandparent vertical FlatList where the three remaining FlatLists and other necessary components will be nested.
One child horizontal FlatList where the remaining two Flatlists will be nested directly in. This enables easy horizontal scrolling between the other nested lists.
The last two grandchildren FlatLists are vertical lists where the image items are nested directly in.

I implemented the mockup immediately and the gotcha became obvious. The problem with this approach was that Scrolling of the nested vertical FlatLists’ content was impeded when the pan was initiated directly in the grandparent vertical FlatList region and vice-versa. It became apparent that my traditional approach to implementing the layout was most likely not achievable. I spent hours trying to research ways to circumvent these limitations but every suggestion introduced a certain trade-off in the desired UX.

To provide more context into the desired UX, a scroll in the composite component should be able to pan any available content in the direction to which it is being moved, continuously; regardless of whichever specific FlatList the content was nested directly in.

Having nested vertical FlatLists with impeded scrolling during content panning was not an acceptable bargain; hence I was prompted to take a not so little detour of building a list that could seamlessly fulfil my layout and UX requirements.

NestedLists

Prior to this exercise I had very limited experience using gesture responders. Although I had basic understanding of React Native’s Gesture Responder System, I had no experience using the more elaborate React Native Gesture Handler. I dived straight into their documentations to get myself armored up to defeat my enemies, I couldn’t afford to be put to shame by mere inanimate objects. 😅

One of my first impressions was the vast difference in ease of usage of the React Native Gesture Handler in comparison to React Native’s Gesture Responder System. One less obvious impression was how React Native Gesture Handler’s seamless integration with React Native Reanimated transformed fluidity and complexity of animations. Hence, I concluded on leveraging on the power boost from the duo. Armed to the teeth with weapons of mass destruction, I proceeded on the journey to build NestedLists. 😂

NestedLists Features

Its layout is structured to have two regions, a header region where the “grandparent FlatList” content (a.k.a NestedLists header) is rendered and a nested lists region where the “grandchildren FlatLists” (a.k.a Nested Lists) are rendered.
Scrolling between the nested lists is achieved by a horizontal swipe in the nested lists region of the component. Panning the entire lists content must complete seamlessly between regions without any restriction in movement.
Scrolling to the NestedLists header region from any of the nested lists, scrolls other nested lists to the top of their content.
Each nested list’s height is solely dependent on the height of its own content
Refreshable - nested lists content should be refreshable
Dynamic content loading – nested lists should be able to load more content upon scroll to end.
Scalable - NestedLists should exhibit features specified above efficiently regardless of the number of nested lists.

Using React Native Reanimated and React Native Gesture Handler, I created animated values (a.k.a Shared Values) which reacted to gestures and drove the animation of Animated Views during scrolling. The Animated Views contained components of NestedLists and were transformed using their “translateX” and “translateY” style property upon update of their animated values.

Using reactive hooks from React Native Reanimated such as “useAnimatedReaction” and “useDerivedValue”, I updated animated values when conditions for their update were met. These conditional updates were key to ensuring the desired UX was achievable.

Performance

To test the performance of NestedLists, I completed my implementation of Instagram’s profile screen and checked if it fulfilled the requirements it was built for. My observations were:

It loads more content dynamically by triggering the “onEndReached” prop provided to it when it reaches towards the end of the list.
It calls the “onRefresh” prop provided to the list, refreshing the active nested list’s content upon trigger.
It has as an optional nested lists sticky header which remain visible at the top of the nested lists, when the NestedLists Header have been panned out of view.
It provides an optional nested lists footer which can be used to indicate loading of more content when necessary.
It also fulfilled the desired layout and UX requirements earlier stated.

I also wondered how performant it functioned so I tracked the JS and UI thread FPS ratings of the Instagram profile screen implementation, using the Expo Go App on an iPhone 7 (to test on low-end devices). I monitored its ratings while the app actively performed operations such as fetching data from remote sources, storing or manipulation of data and rendering of components. Its performance rating on the UI thread was consistently within 60 FPS, the lowest it dropped to after initial mount was 57 FPS. The JS thread was however inconsistent in its ratings. During basic actions such as scrolling through the list content, it consistently reported a rating around 60FPS. The rating however dropped to as low as 30 FPS during rendering of content, manipulation of data, navigation and other JS thread related activities. I was however unable to get any conclusive evidence that indicates the performance lag was indeed caused by the NestedLists implementation.

One other major limitation that flawed NestedLists is its lack of virtualization. Virtualization is an important feature of a performant list as it optimizes resources to maximize performance while rendering list content as necessary. My incomplete understanding of the behind the scenes logic or the optimal approach to designing such a feature is why I ignored it during the implementation of NestedLists.

Conclusion

I enjoyed every bit of trying to recreate one of React Native’s core components as it helped enhance my understanding of how React Native is able to wield the wonderful weapon of deploying applications for multiple platforms without breaking a sweat, well, maybe just a little, okay a lot of sweat 💀. The purpose of this writeup is to open myself to feedback, I am curious about what fellow React Native warriors think about my implementation. Was this a pointless venture with rewards that could have been sowed through less excruciating means? Should I even be trying to reinvent the wheels?

I have linked the repo to my Instagram profile screen implementation, it includes the source code for NestedLists.

Please comment your feedback on what or how I could have done better.