Choosing the right tools for authentication and authorization can make or break your web application’s security and user experience. In this article, we’ll explore the key differences between Supabase and Keycloak, two powerful platforms for identity management. You’ll discover their unique features, ideal use cases, and how they compare when securing modern applications. If you’re looking for a robust, enterprise-grade identity solution, Keycloak offers unparalleled flexibility and security.

With https://skycloak.io hosting and configuring Keycloak is as easy as snapping your fingers, so if you don’t want to run your own containers, just deploy a Keycloak instance with them, worry-free.

By the end of this article, you’ll know when to choose Supabase, Keycloak, or even how they can work together for a seamless authentication system.

What you’ll learn in this article:

• Understanding the crucial difference of Authentication vs. Authorization

• What Supabase and Keycloak are

• How Supabase authenticates and authorizes users

• How to decide if you need Keycloak or if Supabase will be sufficient

• How to connect Supabase with Keycloak

• Realising why using Keycloak can be beneficial as your default Authorization and Authentication system

• Alternative solutions to Supabase & Keycloak

• A final conclusion of the key points

Let’s kick it off.

Authentication vs. Authorization

Authentication is the process of verifying a user's identity in a web application. For example, when you log into a website using your username and password, the system checks if these credentials are valid and match an existing user account - this is authentication.

Authorization, on the other hand, determines what actions a user is allowed to perform within the application. After you're logged in, the system checks what parts of the website you can access or what operations you can perform, such as viewing certain pages, editing content, or accessing admin features. This is authorization.

For example, if you visit the page /admin/show-all-users, the authorization system checks - with your authentication information - if this authenticated user is authorized to access this part of the application.

Understanding the distinction between these two concepts is crucial when designing secure web systems. While authentication verifies who the user is, authorization controls what that user can do within the application.

Supabase

What is Supabase?

Supabase is a popular Firebase alternative that has gained significant traction over the past two years. As of this writing, it boasts around 75,000 GitHub stars, placing it near the top 100 repositories.

At its core, Supabase is essentially a "superpowered" Postgres database wrapped in a carefully curated toolstack.

It's crucial to understand that Supabase isn't a non-standard version of Postgres. Rather, it's standard Postgres enhanced with a selection of excellent extensions and settings, surrounded by services that leverage the database.

For instance, the Auth service (previously called GoTrue) handles user authentication, while the Realtime service delivers user-specific real-time data, among many other features.

Supabase isn't a single entity—it's a comprehensive toolkit centered around the Postgres database. This suite of tools addresses common "Day One" challenges faced by most products, while also offering advanced features like logging and monitoring.

• Where to host the database?

• How to implement authentication?

• How to implement realtime data?

• Where to store files?

• How to implement scheduled tasks?

• How to manager users?

• Where to store secrets?

• How to collect logs and reports?

• How to get data from payment providers?

• etc.

Most importantly: All of those pieces, are open source and can be self-hosted. I personally love using the zero-effort variant by using their hosted supabase.com service.

For more than 90% of my new clients, I use Supabase, even for enterprise level clients. Simply because it just works, is fully open-source and can be self-hosted. Plus, it’s language-independent: Although many Supabase libraries exist, everything is callable via REST API as well.

But now, let’s have a look at Supabase’s Authentication and Authorization.

How does Supabase authenticate?

Supabase uses the Supabase Auth system to authenticate users, formerly known as GoTrue which was initially developed by Netlify and massively improved and extended by Supabase.

In simple words, authentication works like this:

You create a user in the Supabase Dashboard or programmatically via one of the many Supabase libraries (e.g. for JavaScript, or Golang) by providing an E-Mail, e.g. foo@snoo.bar

1. This user is now saved in the Postgres database in a protected place, in the auth schema in the auth.users table

2. 

   When a user then logs in (e.g. because you provided a login form and called the supabase.signInWithPassword() method, the user credentials are checked on the Supabase backend.

3. If the user credentials are valid, a signed session is returned and saved (a so-called JWT which contains also the information when the session expires) - you are authenticated.

4. When you now try to fetch something from the database e.g. with the Supabase JS library via supabase.from('tableName').select('*').limit(1), it will verify on the server if the authentication is valid and trustworthy. If yes, it will execute the commands with the Authorization feature (see below) as the guardian.

From a DX-perspective, the authentication is an absolute no-brainer as you literally only need one small code snippet to sign someone in. Also the creation of a user is just one line of code programmatically.

But what about Google Login or Magic Login then? Let’s talk about that next.

Authentication methods with Supabase

Supabase Auth not only supports logging in via password but a variety of authentication methods such as Magic Link, generic One-Time passwords (OTP Login), Phone login and many 3d-party Identity providers such as logging in via:

• Generic Single Sign On (SSO) via SAML 2.0 (SAML 2.0 Explanation) - which is a standard also supported by Keycloak (amongst many as you’ll see in the Keycloak section)

• Sign in with Keycloak - a very crucial one

• Sign in with Apple

• Sign in with Google

• Sign in with Azure

• Sign in with Bitbucket

• Sign in with Discord

• Sign in with Facebook

• Sign in with Figma

• Sign in with GitHub

• Sign in with GitLab

• Sign in with Kakao

• Sign in with LinkedIn

• Sign in with Notion

• Sign in with Twitch

• Sign in with Twitter

• Sign in with Slack

• Sign in with Spotify

• Sign in with WorkOS

• Sign in with Zoom

• More providers coming

But how to use those within Supabase and does it interfere with existing users? Let’s take “Sign in with GitHub” for example and have a look:

To implement GitHub login with Supabase, you go into your GitHub account and create a new OAuth Application in your GitHub Developer Settings.

There you’ll enter the Callback URL from Supabase (see image) with which GitHub will exchange authentication information.

Then, you’ll get a so-called Client ID and Client Secret from GitHub after submitting your GitHub application form which you fill in the Identity Provider information of Supabase:

That’s all. Now, you are able to trigger the signInWithOAuth({provider: 'github'}) which will forward users to the GitHub login page where they need to confirm that they want to sign in in your Supabase-powered application with their GitHub account.

Multiple providers, same email? Supabase has automatic Linking

A common question is: What happens if you add multiple login options to your applications and have a “Sign in with GitHub”, a “Sign in with Apple” and a standard magic Link (email-only) login?

If the user’s email is the same e.g. ant@supabase.io, and that email is confirmed to be verified by the provider, the identity information is all stored with the same user - hence, it doesn’t matter with which provider they log in, they will always get access to their user data.

Pretty helpful. But what about different email identities, can they also be linked to one account? Yes, check the following section.

Multiple providers, different email but same user? Supabase has manual linking

If there is a user signed into your application, e.g. via GitHub login, but wants to use the Apple Login in the future, Supabase provides a linkIdentity({ provider: 'PROVIDER_NAME' }) function to trigger a signed-in user to be redirected to the chosen provider e.g. PROVIDER_NAME=apple , confirm the sign-in process and be redirected to the application where then the apple identity is also stored and linked to the existing account.

This would then even allow to delete the older existing identity afterwards.

How Authorization works in Supabase

We will now look at how we can give users specific access to specific resources in Supabase.

These two things sound contradictory but are not:

1. You can control fine-grained access to data per user in Supabase

2. The user management UI of Supabase is pretty plain. You can change a users password, you can delete a user, create a new user, request a new password but there is no “Permission Administration” in the user management.

So, how to do the first one, if there’s no such thing as a “Permission Administration”?

Let’s make a specific sample. Let’s take a specific user for that: ant@supabase.io with the user id in Supabase being 005dfbcb-fb85-4955-9a58-a743350218e1 (a normal UUID).

Authorization the “old” way

When a user is authenticated in Supabase, you can confirm it by using the supabase client and calling supabase.getUser() (or manually doing so with the REST API if you prefer that).

Now imagine this Postgres table todos:

If you have a backend in your application, you could now use it to retrieve only the tasks from that table where the user_id matches with the user id you got from the authenticated user

const user = await getUser()
const current_user_id = user.data.id;

const db = await connectWithDb();
const todos = await db.fromTable('todos').select([
  'todo_id',
  'todo_task'
]).where({ user_id: current_user_id });

That’s one solution but it obviously can only run on the backend as you will need to connect with the database with your credentials.

Let’s now look at the solution that became popular with Supabase: Authentication-bound Row Level Security.

Authorization with Row Level Security, Introduction

Row Level Security (RLS) is not a Supabase invention, it’s again a Postgres standard. If RLS is enabled on a table it means no one but admin roles in the database will be able to read or write on that table by default.

If you’ve only worked with databases the old way, this approach might seem new to you since many people only use one postgres root user to connect to the database and not multiple different roles. So, let’s get into it deeper to understand how it works and why it’s wonderful.

Let’s stay on the raw database level at first. If you create a new Postgres user (=role) in the database, you could give that Postgres user read access to specific tables or even specific rows within a specific table (that’s why it’s called Row Level Security).

For example, if you created a Postgres user foobar, you could give that user access to only the second todo in the todos table with this SQL:

ALTER TABLE todos ENABLE ROW LEVEL SECURITY;
CREATE POLICY "foobar can only access one row"
ON todos FOR SELECT
TO foobar
USING ( todos.todo_id = 2 );

Now, when you would connect with this foobar user to the Postgres database and that user would run a SELECT * FROM todos , all the database would return would be just one row.

But this is just the raw explanation of RLS. How can we bind it to a Supabase authenticated user? is every Supabase user its own Postgres user? No, not really, but there’s something that eludes this requirement. See next.

Authorization with Row Level Security, using the auth.* functions of Supabase

We’ve covered 2 things:

1. How to use the user_id to limit what we return - as a root user connected on the backend to the database. Which you can do in Supabase because it’s just Postgres.

2. What RLS is in general: a way to restrict row access to Postgres users.

What we now want to do is:

1. Using RLS to bind it to a Supabase user without even the need to connect directly to the database and be able to safely use the connection both on frontend and backend without exposing secret data. Sounds exciting, right?

Let’s go through it step by step. The Supabase client, or more generically, the Supabase API, allows to request data from Postgres by constructing commands (similiar to what an ORM does).

In JavaScript, you can request data from the todos table via Supabase like this:

const supabase = createClient(SUPABASE_URL, SAFE_SUPABASE_ANON_KEY);
const { data } = await supabase.from('todos').select();
const todoData = data; // just to be very explicit here

But will this contain all todo entries? Even if we call this in the frontend? Can we even call this on the frontend? Yes, we can call this on the frontend as the anon key of Supabase is safe to expose (as opposed to the Supabase service_role key which is not safe to expose as it has admin rights).

But what will it return? By default, tables created in Supabase have RLS enabled. Hence, this request would go to the database and, if no POLICY is defined on that table, simply return everything that the existing policies allow: nothing, an empty array, 0 rows. So, it’s safe by default.

But what happens in the background? How would it know if a user has access or not?

When the request is sent to the API (which is the PostgREST library), it will take an existing session, verify it and then execute the SQL statement either as anon role in the database (if no valid authentication is available) or as authenticated role. So it will definitely execute that SQL statement in the database but those 2 roles don’t have admin privileges and hence, with activated RLS and no defined policy, nothing is returned.

This opens 2 questions:

1. Why would I want to give the anon role (so no authentication) give access to data?

2. If every user has the same role, how can I prevent that one user can access data from another user?

The first question is rather straightforward to answer: Imagine a news page. You want non-logged in users to be able to read entries from the top_news table. This would be easy to achieve in Supabase by simply executing this SQL:

ALTER TABLE top_news ENABLE ROW LEVEL SECURITY;

CREATE POLICY "everyone can read the news"
ON top_news FOR SELECT
TO anon
USING ( true );

This however specifically targets the non-authenticated users but you literally want everyone to be able to read so you can simplify it with this statement:

ALTER TABLE top_news ENABLE ROW LEVEL SECURITY;

CREATE POLICY "everyone can read the news"
ON top_news FOR SELECT
USING ( true );

Now, let’s jump to the second question. We cannot simply do something like this as it would allow all authenticated users to access all todos entries:

CREATE POLICY "authenticated users can read todos"
ON todos FOR SELECT
TO authenticated
USING ( true );

But, within the database there is a helper function to make it more specific. It’s called auth.uid() and it is always the id of the currently authenticated user (or null if not authenticated). That means, we can do this:

CREATE POLICY "authenticated users can read their own todos"
ON todos FOR SELECT
TO authenticated
USING ( todos.user_id = auth.uid() );

Now, when a user is logged in and const { data } = await supabase.from('todos').select(); is executed, data will really only contain user-bound data - authorization solved.

Keycloak

What is Keycloak and why is it so popular?

Keycloak is an open-source Identity and Access Management solution that solves both Authentication and Authorization for applications. It's highly regarded for being enterprise-ready, open-source, and supporting all well-known standards, making it the go-to solution for companies needing a robust Auth system.

Keycloak offers a centralized system for user management, single sign-on (SSO), and identity brokering. This makes it particularly attractive for organizations grappling with complex identity management needs. Its flexibility and extensive integration capabilities have fueled its widespread adoption in enterprise environments.

But does that mean it should only be used for enterprise projects? No, but it is a good choice for enterprise projects.

But let’s have a look at how Keycloak solves authentication and what types of authentication it supports.

How does Keycloak authenticate and what authentication methods does it support?

Keycloak is your authentication manager. You can manage users and user permissions directly in Keycloak without the need of any 3d-party identity provider - however, Keycloak does support identification via every 3d-party provider.

Same as Supabase, Keycloak allows you to create users and login with those users directly with Keycloak.

Keycloak supports various authentication methods, including:

• Username and password authentication

• Two-factor authentication (2FA)

• Social login (e.g., Google, Facebook, Twitter)

• SAML 2.0

• OpenID Connect

The connection between your application and Keycloak will always either be done via SAML or OpenID connect. But don’t worry, you don’t need deep knowledge about these standards to use them.

When a user attempts to log in, Keycloak verifies their credentials against its user database or the configured identity provider. Upon successful authentication, Keycloak issues tokens (such as JWT) and responds back to your application. So it’s all very similiar to how Supabase solves authentication - so far, so clear.

Authenticating with pure Keycloak

Let’s make a concrete sample: We have an application, e.g. a Laravel PHP app or a Next.js app called “my-app” and we want to log in with a user via Keycloak. How would that work?

1. You need to create a so-called “Client” in Keycloak; the client is the bridge to authenticate with your application. This is easy: In Keycloak, click on “Clients” and then an “Create Client” and give it a client id, e.g. my-app

   

2. You need to have a user created to even be able to log in at all, so head to the Users section and click on “Create new user”

   

3. In this user creation form, the only required field is “username”. This is interesting because the username doesn’t have to be an email, it can be any alphanumeric name. Also, it doesn’t ask for a password at all, so how will the user be able to log in? We will solve this question soon

   

4. After you click create, you’ll see the created user with a lot of options attached to it - this is already giving an impression of the power of Keycloak.

5. 

   Before doing anything else, we need a way for maria to authenticate. We’ll use a password to be able to log in. You can just go to the Credentials tab in Keycloak and then set a password for that user. But even more so, you can also require that Keycloak prompts the user, after using that password, to set a new password - with the Temporary checkbox. Neat, right

   

6. Now, we want maria to be able to authenticate in our application with that Keycloak user. How do we do achieve that? Without noticing, we created an OpenID Connect (look at the screenshot from point 1) standard client in Keycloak in step 1, named my-app. We now need to do two things:

   1. Make our application (let’s use a JavaScript sample) request authentication from Keycloak and make Keycloak return a valid session for a valid login to our application.

   2. Tell Keycloak that our application is actually allowed to request authentication that (by default no application can access anything from Keycloak)

OpenID connect is a standard and Keycloak exposes the required information to connect via this standard at this URL in JSON format: your-keycloak-url/realms/master/.well-known/openid-configuration ; or, in my specific case on Skycloak the URL is https://skycloak-id.app.skycloak.io/realms/test-realm/.well-known/openid-configuration . You don’t have to read those values manually but it’s something nice to look at (these are not secret values very obviously but the client needs those to connect).

If you ask yourself why I have test-realm in my URL instead of master: Keycloak allows to use multiple separate contexts called Realms. E.g. you can manage 5 completely separate applications with 5 different realms. Another Keycloak advantage, think of it as “Multiple Keycloaks in Keycloak”.

But let’s get back to how we can request an authentication with our JavaScript application. For this, you simply need to use and configure the Keycloak library - so, in our case, the JS library keycloak-js.

7. Instantiate the Keycloak instance like so:Instantiate the Keycloak instance like so:

    import { Keycloak } from 'keycloak-js';
    const kc = new Keycloak({
      url: '<https://my-skycloak-id-xabcy.app.skycloak.io>',
      clientId: 'my-app',
      realm: 'test-realm' // "master" by default
    });
   

   Now, nothing happens yet. We need to tell the library to check and require an authentication. E.g. like so:

    const keycloak = new Keycloak({
      realm: 'test-realm',
      url: '<https://5b77dccb-0080-4629-a47a-ab5b18a50a4c.app.skycloak.io>',
      clientId: 'my-app'
    });
   
    window.onload = () => {
      keycloak.init({ onLoad: 'login-required' });
    }
    //....
   

   My app runs on localhost:3000 and will then, on page load, trigger a redirect to authenticate to Keycloak and show an error like: “Invalid parameter: redirect_uri”. This is because we haven’t configured localhost:3000 (our app) to be legitimated to authenticate with our Keycloak. Let’s change that.

8. We can configure the allowed redirect URIs by going to our my-app client in Keycloak and adding our app’s url like so: http://localhost:3000/* (so any URL on localhost:3000 shall be legitimated to request authentication from Keycloak)

   

   When you save that and then try again opening your page and click the button,you will not see an error but the login form from Keycloak. Here, I can now enter maria as username and the password credentials I’ve set:

9. 

   After logging in, Keycloak immediately asks us to change the password to something new:

10. 

    Once done, Keycloak will usually also ask for providing an Email and Name but you can turn off that these fields are required in your Keycloak Realm settings in the sub section User profile. After those initial actions, you’re headed back to the application page and the keycloak library will have saved the session in your app - you’re now authenticated via Keycloak with the user maria.

11. You can now load the user profile object - and hence verify the successful authentication by e.g. adding a button that triggers it

    <button
         type="button"
         onClick={() => {
             keycloak.loadUserInfo().then((profile) => {
             console.log('profile', profile);
           });
         }}
        >
        Load profile
    </button>
    

12. A basic authentication flow with Keycloak: done ✅

Let’s now have a look at how Keycloak would help to give access to specific data (Authorization).

Authenticating with 3d-party providers or SSO in Keycloak

You've just learned how to use Keycloak for user authentication. Now, let's explore how you can integrate third-party providers as Identity Providers (IDPs) in Keycloak. For example, GitHub. When set up, Keycloak will add a "Sign in with GitHub" option to its login form, connect with GitHub, and store the user information in Keycloak.

To set this up, navigate to the "Identity Providers" section in Keycloak. You can choose from pre-defined providers for a straightforward setup, or if your desired provider isn't listed, you can define it manually according to the standard protocols.

This flexibility means Keycloak supports any Identity Provider that uses the common standards OpenID Connect or SAML—which essentially covers almost all providers.

How to authorize with Keycloak: A fine-grained permission system

The simplest approach to authorization is what we discussed in the Supabase section: saving a user's ID alongside data in the database to control access. This method works regardless of whether you use Supabase, Keycloak, or any system that provides unique user IDs.

Keycloak, however, offers a more sophisticated permission management system. Let's take a quick look at it.

If we check the "Role mapping" tab for our maria user in Keycloak, we'll see a default-roles-... entry. Using the Keycloak JavaScript library we set up earlier, you can access an authenticated user's roles via keycloak.realmAccess, which includes this default-roles-... role.

In Keycloak's "Realm roles" section, you can create new roles and nest them within others. For instance, you could create a "content-admin" role and include "content-editor" and "content-publisher" roles within it. You can then assign these roles to users and check them on the backend using keycloak.realmAccess to manage access to specific actions in your system.

For example, if you assign someone the "content-admin" role and another person the "content-editor" role, you'd only need to check for "content-editor" permissions, as "content-admin" already includes "content-editor" capabilities.

Keycloak's functionality extends further, allowing you to assign attributes to roles and use these roles to manage internal Keycloak permissions if desired.

In summary, Keycloak provides a role-based system with inheritance and fine-grained attributes for roles. This approach makes role management and assignment more flexible and independent. You could even create a Keycloak user with the ability to assign only certain roles to other users, which could be useful for a service team.

Remember, though: These role definitions and attributes in Keycloak only take effect if you design your application's backend to check for these roles.

Keycloak or Supabase?

On the surface, both Supabase and Keycloak use the same standards to authenticate a user and, in theory, both support arbitrary providers since Supabase also supports the generic SAML 2.0 standard. However, SAML is a standard that is more used in enterprise contexts. E.g. using SAML with GitHub is only possible in GitHub enterprise as of today.

Let’s have a look at when to use what and if it makes sense to use both.

When should I use Keycloak over Supabase?

There are multiple reasons that would pinpoint to using Keycloak instead of Supabase:

• You need to support identity providers that Supabase doesn’t support

• You need to have enterprise SSO support e.g. connecting Auth with an enterprise MS365 login

• You want real emailless logins

• You need to support User Federation systems such as Kerberos or Ldap

• You want to decouple the database management UI from the user management UI

• You want to be able to manage user permissions in a UI

• You want to create a team of people to be able to manage users and their permissions

• You need a more complex and flexible role-based access control system that goes beyond simple user permissions and you want to manage it in one centralized IAM UI

• You require detailed audit logs of user authentication and authorization activities

• You want to manage multiple different Authentication providers for different applications, e.g. for different clients, in one place (you can use one Keycloak with different Realms, no need to have multiple instances of Keycloak)

• You want to define authentication flows / rules such as requiring users to change their password every 6 months

• You want to easily and fully impersonate users with the click of a button

• You want to separate the Auth system from the database system to stay more flexible long-term

There are certainly more things Keycloak can do but the above list should provide a good first measure for you to decide if you want/need Keycloak.

Let’s have a look at Supabase.

When should I use Supabase over Keycloak?

Choosing between Supabase and Keycloak often depends on the specific needs of your project. While Keycloak excels in complex enterprise scenarios, Supabase offers a streamlined, developer-friendly approach that can be ideal for many modern web and mobile applications. If your project doesn't require the advanced features that make Keycloak necessary, Supabase can be an excellent choice. Here are some scenarios where Supabase might be the preferable option:

• You’re using Supabase anyways due to its database, storage and realtime capabilities and now also need authentication

• You want a simple, integrated all-in-one solution for authentication and database management

• You don’t need to manage different apps / clients with the same Auth system

• You want to directly bind database data access to users as shown in the RLS samples in the previous Supabase sections

• You want to build your own role management system by reflecting roles and permissions in the database

• You're building a new application and don't need complex user management features such as requesting password rotation routinely

• You don’t need the ability to invalidate current sessions via the UI

For many people that are building an application with Supabase, the built-in authentication and authorization features will greatly be sufficient to also build complex projects.

But end of the day, you have to make your decision and you might even want to use both. Let’s look at that combination now.

How and why to connect Keycloak with Supabase and use both together

We already discussed that you can use a 3d-party login with Supabase such as “Sign in with Google”. Keycloak can do so too. But you can also do a “Sign in with Keycloak” which will then e.g. go to your SkyCloak.io (hosted Keycloak) instance so suddenly your wonderful Keycloak becomes the authenticator for Supabase.

This is super easy to achieve. You would be using Supabase and its libraries to authenticate with Supabase and, when doing so, Supabase would request that authentication from Keycloak. So technically, your application will redirect to Supabase and then Supabase will redirect to Keycloak. Keycloak will do the authentication and give the result back to Supabase. Then, if everything went well, Supabase would respond with a Supabase authentication to your application.

This allows you to manage users within Keycloak whilst making use of all Supabase Auth features. A pretty insane combination and also easy to set up. To achieve that, not your application, but Supabase itself will be a client of Keycloak. So, in Keycloak you would create a new client called “supabase”, set the authentication type to confidential (Client Authentication On) and provide the Callback URL from Supabase (your-supabase-url/auth/v1/callback) as Redirect URI in the Keycloak client creation:

Then, you need to move to the “Credentials” Tab of that Keycloak client to obtain the client secret. Copy it into your clipboard:

After that, go into your Supabase instance, move to the “Providers” section, open Keycloak, enable it and add the client id, the obtained secret and the Realm URL of Keycloak as follows:

After creation of that connection (click “Save”), you can now use Supabase to log in via Keycloak. E.g., in JavaScript you would trigger an authentication with:

supabase.auth.signInWithOAuth({ 
  provider: 'spotify', 
  scopes: 'openid profile email' 
});

That also means: You can then connect to Keycloak any identity provider you want. You now have: The universal solution: You can manage users in Keycloak but use them with Supabase and also use the authorization methods of Supabase.

Supabase will still obviously create a user copy (requiring a user to have a valid email) but it will only authenticate and verify that user with Keycloak.

Supabase will then create a Session token which contains the Supabase data as well as the Keycloak session data. The latter is saved in supabaseSessionData.provider_token . That means that you can also read the Keycloak token directly from the Supabase token and e.g. store the role / permission information there.

Now it’s up to you to decide which solution you want.

How Skycloak makes usage of Keycloak even easier

SkyCloak is a raw but fully managed Keycloak deployment system. It fully takes away the pain of deployment which is indeed a crucial point when it comes to efficiency. Using Keycloak is one thing, deploying and configuring it properly is another.

Forget about that and just use it. With SkyCloak

you can focus on building your application while leveraging the powerful features of Keycloak. SkyCloak handles the complex deployment and maintenance tasks, ensuring your Keycloak instance is always up-to-date, secure, and optimized for performance. This allows you to take advantage of Keycloak's robust authentication and authorization capabilities without the overhead of managing the infrastructure yourself.

As expected when posting, some users claim that I picked one specific sample. I can't put all samples here that I found, this blog post would be endless. You are very welcome to check the code yourself, with Code Complexity linters and your own thoughts enabled - it's OSS.

Clickbaity title? Maybe. But it gets the gist. And before you think "this is just another hate post / opinion", well read on, I digged the source code deeper than many ever go and I did so for good reason.

Also, I've used tools to prime and underline this with facts. See all of my projects aren't perfect - at all - nor is my code. But, let me tell you that I've been migrating the hugest enterprise stacks with integrated linting in the pipelines from repo to jira, so I know what it means to fix "bad" code - whichever way you define it.

I care, a lot!

Next.js is my go-to framework for projects. This is why I care so much about it and why I do this blogpost, because the insights honestly scared me.

Funnily there are often many individuals that think I'm "hating" on Next.js. There is in fact no tool I use more than Next.js. I like using it. Even more so it's important to adress it's problems. Also I did write Lee Robinson a message before posting this but he didn't respond. So did I tag the CEO in a Twitter thread

Why did I even check the Next.js source code?

Well, funnily, I didn't with the intention to write a blog post. In fact, I wanted to find out why setting a value on the request object inside of the middleware won't be available in it's subsequent renderings (like e.g. the page component). This isn't obvious at all. As it's the same request, you can easily expect it to be reused - it's part of the same code logic / loop as I found later so even more so that would be a reason. But it's not. And I wanted to know why.

I often dig into foreign source codes of big projects to understand what happens under the hood. Mostly to provide the correct solution for my projects. Usually, I get a good feeling after like 1 hour. E.g. digging into any repos of the Supabase organization on GitHub, although it's complexity, is always kinda straightforward.

Now with Next.js, it was very very very different. I started digging on a Sunday, with a few breaks in between, I found the reason for the behaviour on Tuesday. It's not like I didn't have an assumption, but I had to prove that my assumption is correct. I expected a few files to be involved but not this mess only to find out one single thing.

I created a Notion page to keep track of what I'm seeing because the complexity was so high that it was impossible to keep it in my head. The resulting page that didn't even include everything that really happens (I left out a few things that I felt weren't needed to understand the whole thing) had 3300 characters, 430 words. That's a short blog article basically (i would give you a screenshot, but the notes are german and I didn't want to translate all of it).

Edit: Used ChatGPT, here's a screenshot. Please note that this might look "normal" to you by just reading it, but this isn't even complete and pathtracing this took ages, there are extreme amounts of conditions, function calls, etc.

Okay, so will you tell us the result at least?

Sure! NextJS resolves routes all together (interesting, right?) and then loops them (tl;dr version).

The request object is then copied. But not because it makes sense (it does make sense but given the code naming, it's not because of that) but because it needs to be converted and extended with NextJS values. The specific code is const normalizedReq = this.normalizeReq(req) and it's being passed the original, non NextJS-extended req object and if normalizeReq recognizes that it's not a NextRequest it will make one by copying the values of the given req. Weirdly, if one would start contributing that isn't aware of that exact thing, the behaviour could change to sometimes actually being the same object (if it's of the NextRequest instance already). But yeah, let's not discuss this code detail here.

Again: although it makes sense, it is all but obvious.

Let's define bad code

In very short terms: Bad code isn't just technically bad code (like code with failures). Bad code can be code that works perfectly but is so convoluted that it's only understandable after hours of digging or after asking someone else who is long enough in the code. Bad code can also be code that only holds on to work because there are tests so as long as no test breaks, we can trust it works, but we don't know why. There's multiple definitions of "bad" but none of the definitions is one you'd like your code to be aligned with.

Let's have more source code insights from Next.js complexity / DX

I've installed two rather well-known utilities, the SonarLint (very well-known) and the CodeMetrics (https://github.com/kisstkondoros/codemetrics).

In fact I didn't need those tools to determine that NextJS is a big bunch of "wtf is going on here?". Try it on your own, check out the Next.js repo and make it your task to find e.g. "where does Next.js call server actions". Tell me how much time it took (FYI, I don't know this, i just picked a random question that came to my mind).

Let's take another sample of the same file (which is small with ~800 lines considering the fact that I've seen some with 3k+ lines):

resolve-routes.ts#232:

Before we get to the checkTrue(), I give you this: As the filename states, resolve routes resolves routes (didn't think of that, right?). What do you think checkTrue() does - besides the fact that it's body has increased complexity? Does it check true? True for what? Can't you tell? Me neither. There's also no comment that explains it. I cannot think of a single use-case, no matter the project, where it would make sense to define a function named checkTrue() . I cannot.

I'll give you a bit more code, just the start:

How about now? checkLocaleApi ? Didn't we developers agree that a well-readable code with if's should actually state what it does? Like isLocaleaApi? And what does that one do? Can we hover it?

Ah, perfect, it returns true or undefined. That clears it up. Not. Given it'd be named isLocaleApi I could at least make some sense of it. Although, a quick function definition comment wouldn't harm, with maybe even references to related files, would it?

I'll stop with this now. Every single file within the Next.js repo that has a few hundred lines has stuff like this all over the place. It's not "one pick". It's everywhere. Go have a look for yourself.

That's because Next.js is a complex project!!!!1111

There's one thing I can certainly say: Overall Complexity of a project (it being big having many features and dependencies) does never justify bad DX. Never. It explains it, but it doesn't justify it. Never in my career have I noted: Let's make this shit complex as fuck because it's requirements are complex. In fact, quite the opposite. The more complex, the more I try to seperate and structure.

I have contributed in big projects where I didn't know the language even, simply because the code was well-written and well-structured so I could follow along and contribute.

Given semantical complexity in fact is a major, major reason to remove the complexity in the code. This can always be done. By using code quality linters, by defining max file sizes, by having proper, clean code reviews, etc., you name it.

There is one rule that goes way beyond development and more often than never has proven to be effective: Conquer and divide. For instance, team splitting with responsibilites on certain features with splitted repos (can be a monorepo with separated folders, whatever) will lead to teams owning these features and overall often more code but more code that is well structured - if done right.

But David, do you always create perfect projects?

In fact, sometimes I do know that my code is shit code (is it a skill to accept ones own shit code?). But in own projects, you can do so. I didn't need superclean code in my landingpage. Who cares? Even more so, sometimes doing an MVP with 100% shitcode and then throwing it away and redoing it is also a thing I've done and it was worth it.

I do however care in a fintech banking application or generally in contexts that need longevity and fast onboarding. So, DX depends very much on the context but I'd say having an open-source framework with millions of end users, that's a good point to think about awesome code clarity, not even "okayish" but awesome.

What's your take away now David?

I don't know really. I'm not hating. I'm desperate due to what I saw. I tried to reach out to some Vercel guys but I'm not sure if they didn't read or just don't wanna hear it. I'd love to hear some thoughts from them, hearing their opinion on the status quo, to see their actually listening.

Like I'd be interested if there is a method within their team that tries to "decrase code complexity" which goes hand in hand with e.g. linters because I'd really be interested if they just said "Okay SonarLint, complexity of 300 is just GREEN all the way".

What's for sure: I won't, no actually I cannot contribute to Next.js in it's current state as it's, without a doubt, the only project I've seen which was so convoluted in so many different places that I consider my old, hated enterprise project with full-blown shitcode easier because it was well-structured and I could migrate it step by step (took about 2 years, but we did it).

Please note: I'm not bashing Next.js here. I'm using Next.js still everyday but I really needed to get my thoughts and critics out there to see if people do share my concerns. There is a lot of good stuff about Next.js for sure, otherwise I wouldn't have used it for so long, but right now the bad things seem to overshadow the good.

Earlier when people asked questions about Next.js (v12, Pages Router), it was quite easy to simply pinpoint to the docs. Most of it was easy to understand, people understood that if they want to embark on server-side data, they can do so using getServerSideProps or getStaticProps. Pretty clear, intuitive.

I am an architect of 23 years development experience now. I can surely state that I am happy I could develop an awesome skillset but I probably spent the most time with JavaScript. That being said if I am thinking about Next.js being not intuitive enough or too complex I can only imagine people with fewer experience struggling.

Since v13, Next.js tries to push Server-Side-Rendering to the fullest but it doesn't feel complementary anymore but instead seems to wanting to replace frontend. I mean this is cool in the use-case where you actually want that, say a contentful news page or an e-commerce shop. But for an extremely fluid, reactive application with beautiful user interaction, things got way more complicated.

The problem isn't SSR, at all. SSR is lovely and important. The problem is, that we are hyperfocused on enforcing SSR and right now it doesn't seem quite reasonable anymore. If Next.js could trigger onClick on the server, they probably would. And this is where it gets ridicolous: Solving a problem that didn't want to be solved. But let's get into actual issues.

Caching without asking

With v13, Next.js started caching your internal API requests implicitly. Means: If you use fetch for grabbing weather data, you'll get old weather data the next time you fetch it. Thanks to automatic caching. Sure, you can disable it. But this is a breaking change and React itself has a known guideline that it's tailored for enterprise not having breaking changes like that (https://legacy.reactjs.org/docs/design-principles.html#stability). So even though React and Next are extremely close, Next didn't seem to adhere to the same design principles. Having such a caching mechanism is surely awesome, if you can enable it - either globally or partially. But I'm confused that amongst all architects, no one said: it shouldn't be enabled by default changing the way your application works in a world where probably most API requests should not be cached.

The whole thing lead to an answer in the form of explaining the caching (https://www.youtube.com/watch?v=VBlSe8tvg4U). There's a saying though: If you need to explain it, it's not intuitive enough. But the thing is: it was explained in the docs (which makes sense) so rather the saying is: If you need to explain it over and over again, it's definitely not the best solution. (Still, thanks for the video, it's a good one!).

Let me say this: From a technical perspective, seeing what they did, I'm amazed. But as given, it's something no one asked for. I would've rather had something like an explicit caching mechanisms allowing me to CONTROL my app better and not letting my app be controlled by a simple upgrade. Especially because this existing mechanism leads to the problem that I cannot cache requests that I want to cache, e.g. when I'm using Supabase and fetch data from it, it will always skip the cache - which usually makes sense but if Next had explicit caching, I could just put the result to the cache - oh well, in fact, you can, it's just hidden: https://nextjs.org/docs/app/building-your-application/caching#react-cache-function but, again, comes with pitfalls: https://react.dev/reference/react/cache . So much to know for a rather simple thing to achieve.

The other problem about that caching is that there are a lot of additional things to consider. For example, if you want to force a page to refresh, you can actually call router.refresh() one the same page or revalidatePath . Unsure? Well that's easy, here's what the docs say:

revalidatePath vs. router.refresh:

Calling router.refresh will clear the Router cache, and re-render route segments on the server without invalidating the Data Cache or the Full Route Cache.

The difference is that revalidatePath purges the Data Cache and Full Route Cache, whereas router.refresh() does not change the Data Cache and Full Route Cache, as it is a client-side API.

All clear? No? Well you're not alone.

No instantaneous UX feedback when loading

If you're a user of Next.js and just added standard pages, you surely will have noticed, even on localhost, that sometimes it feels like the page is stale. You click a link, nothing happens and then, after a few moments, swoosh. This was less worse in the old PHP times where the browser indicated loading behaviour in the URL bar, then the page went white and users knew "aha the browser is loading a new page". With Next.js it feels like "nothing happens" and then suddenly the moment "ah ok well it did work".

Again, Next.js "solved" this by allowing you to add a loader.js at the level of the page you are loading. The problem is though: The loader has to be loaded - for the sake of performance. I'm not sure if I should laugh about this. The loader's goal, UX-wise, is to be instantaneous to provide user-feedback. Period.

Now Lee Robinson says that this is by design because otherwise they'd have to preload all the loading spinners because they wouldn't know when to load which and if you got like 100kb spinners this is way too much. This sounds like a "Well, we sat in a cave and thought about unrealistic use cases to prevent instead of asking real people". See, my current loading spinner has 100bytes. Take 10 and make them 10 times the size, that's 10kb in total (!!). Already this is exaggerating for my use-case but 10kb additional bundle size for my web application to feel fluid: not a problem at all, it's a joke of additional payload, especially if it was lazy-loaded after the critical content.

Logically, this current idea of how the loading spinner is implemented doesn't make sense at all. So here, Next is basically patronizing the developers in the sense of "I know better what's good for you".

Here are potential solutions:

• Let me choose which loading spinners to include in the bundle (e.g. by exporting a const or setting a global flag like bundleAllLoaders: true in the next.config.js)

• Let me prefetch the spinner only, not the page. Here's a very reasonable case: A ticket creation form which will lead to the ticket details page afterwards. The details page cannot be prefetched fully because the ticket is about to be created so there is NO WAY of prefetching the page - but there is sense in prefetching the loader. So, let me call router.prefetchLoader('/ticket/details/[id]')

Server actions were published without security advise

I don't wanna go too deep into that topic as I've made a video about it: https://www.youtube.com/watch?v=j0_g8Redd0A. The thing is: If you use Server Actions as part of your component and load data with credential keys, the credentials are bridged via frontend without you noticing. Some people said in the video: Well, that's obvious because it's a closure. But in fact: It's not a normal closure. This isn't "standard javascript". Nothing here is obvious. Server Actions themselves aren't obvious because they're extracted from the actual component and in times where bundlers do the work and something like Server Actions are presented without further warning or advise considering that, I can expect that they're being extracted without passing my credentials.

Knowing what happens it's easy to bypass but the problem here again is: The upgrade essentially delivered a new problem. Maybe it would've been more clever to not allow the action definition in the component itself.

It's sometimes painfully slow

When an SPA was slow it was pretty easy to debug. It was either the server response that took too long or something in your frontend code was rubbish. With the hybrid approach and the implicit caching mechanisms sometimes you're waiting and you have to dig deep to find the root cause - sometimes without any success.

What I find especially troublesome is the fact that the dev experience doesn't reflect the prod experience at all. It's known that Next produces an optimized output for npm run build but it's not clear on the other hand that sometimes the dev server is kinda hanging itself on a machine that can handle gaming, video cutting and coding at the same time. The worst part is that it's not clear why this happens but it doesn't just happen to me.

Serverifying frontend

I was thinking about this a lot. I'm a huge fan of SSR. But what worth is SSR for interactive apps like e.g. Canva?

I remember the times when headless was the way to go. We all used SPAs like React or Angular and loaded data from the server. A pretty good approach with the disadvantage of having a lot of code in the frontend. That however was solved by having the option to lazy load. Back then, we noticed we need immediate server-rendered pages especially for search engines so we rendered the SPAs output as well on the server and hydrated it.

Now, I feel like Next pushes hard on people to use server-side features as far as moving frontend functionality to the backend. I like having the option, but using the server for everything might not be the best advise.

Let's take for example useOptimisticUpdate. The sample shows how to trigger adding a Chat Message and how it can be shown in the frontend even before it's done adding on the backend (https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#optimistic-updates). It sounds good, and it isn't bad by all means. But the problem is, that you're not in control of the state. Once the server is done, it will update the state and re-render the list. Sounds good so far as well but here's my take:

If I wanted to create a ToDo-list that allows adding an entry and immediately being able to drag'n'drop it, this approach would interfere with the interaction and re-render the list. If there was some kind of middleware to the useOptimisticUpdate hook like useOptimisticUpdate(..., { onBeforeUpdateFromServer } => finalState) as well as a setState to control its content, this would be different. To overcome this, you'd need to complexify it as far as I'd choose another approach anyway e.g. using my unglitch library.

But that was just one very specific and, frankly, not limiting example because I'm not forced to use it.

What is a limiting factor however is the fact that every page request is now hitting the server. Transitioning with SPA routers between pages was rather simple because we were just replacing components in a parent wrapper and had the appropriate listeners to do easy transitions. Now, with Next.js this is still possible but it honestly feels like there's more mental load to it (https://github.com/vercel/next.js/discussions/42658).

Also, as stated, for super-interactive Apps like Spotify, I wouldn't want a frontend page switch to trigger backend at all as my Server Component might've fetched initial data that isn't supposed to be fetched anymore when we're already on frontend (e.g. a user id). Hence, I asked myself if I can trick portions of my Next.js app into acting like it was an SPA. Indeed I could, but I'm not sure about the implications:

export default function SPAPageInsideNext({ searchParams }) {
  const p = useSearchParams();
  const r = useRouter();

  const isFooInitially = searchParams.foo === "snoo";
  const isFooNow = p.get("foo") === "snoo";
  return (
    <div>
      Is this an SPA? 
      <div>isFooInitially = {isFooInitially ? "yes" : "no"}</div>
      <div>isFooNow = {isFooNow ? "yes" : "no"}</div>

      <button
        type="button"
        onClick={() => {
          if (p.get("snoo") === "foo") {
            history.pushState({ foo: "snoo" }, "foo-snoo", "/spa?foo=snoo");
          } else {
            history.pushState({ snoo: "foo" }, "sno-foo", "/spa?snoo=foo");
          }
        }}
      >
        Toggle Param
      </button>
    </div>
  );

So instead of router.push, I'm using the native history.pushState, ensuring on reload it will be the correct URL (deeplinking) and it indeed triggers a re-render without server request (i thought it ignores the re-render part, but it makes sense considering onClick runs in the react lifecycle).

Is this good? I didn't dig deeper, so I can't tell yet. But it's definitely good to know. However I'm scared it comes with pitfalls I haven't discovered yet.

This is indeed an official solution as stated in (thanks to a Reddit user pinpointing to it) https://nextjs.org/blog/next-14-1#windowhistorypushstate-and-windowhistoryreplacestate .

Vercel Marketing vs Vercel Target group

I know it has been some time since Turbo was announced but the thing is: I feel taken for an idiot if the claims given are far beyond the truth - developers are seeking for things that are of value and if something has just 10% more speed than before, that's cool. But if you're saying that something has like 1000% more speed and in fact it's a lie (https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussions/8) it doesn't create a trustworthy bond. Just my two cents on this one.

Conclusion

I was lately seeing some React-only or even Angular apps that went without SSR approach. My first thought: Why not choose SSR, Next.js whatever. But at a second glance I noticed they were extremely speedy. Everybody nowadays says that rather than choosing React one should choose Next. I'm not so sure anymore. If you create a wonderfully splitted SPA with even manually controlled lazy-loading, React can serve you well, depending on your use-case.

Sure, for an e-commerce app with contentful pages, Next.js would probably be my first choice. I'm just re-evaluating the "Next.js for everything" case.

There's too many things in the open that I feel like I really want to try another framework (I love React, so maybe I'll give Remix a shot) to see if there's one that gives me less mental load and a better feeling of confidence.

These are just the things that came to my mind recently.

So my primary questions are: What are your thoughts? And would you consider Next.js being an awesome choice for a fluid interaction-rich application like Spotify or Canva?

Cheers

If you don't wanna spend any money you can use my DigitalOcean Link - which gives you 200$ of Free Credit for 60 days, enough to do anything.

The standard self-hosting Guide from Supabase, as of this moment (August 2023) cannot be used for production deployments. It is insecure but it's gonna be the pathway for a proper setup.

The concept and the realization of this took me multiple days. Actually, there is a YouTube Video for you to follow up:

The reason why I am also making it a blog article is simple: The blog article is technical foundation of my YouTube Video and allows you and me to easily copy config data.

1. Setting up Storage (beyond Amazon S3)

Yup, this should be your first move. Simply because changing this afterwards is a Pain in the A**. And the best part: You don't have to decide, you can just leave it as is (1.1)

Option 1: Volume Storage 👉🏾 You probably don't need S3

Supabase-as-a-Service (supabase.com) is using S3 Storage. What that is? Well, basically an API that allows storage of files on a server and that server can replicate and backup those files (that's the short version).

Now everybody goes "Yeah, backups and stuff and scaling, I need that". Nobody said you don't get that without S3. If you are using a Server from e.g. Hetzner Cloud then you can simply choose their Volumes for file storage and activate backups. The same goes for providers such as DigitalOcean. So basically you're all set with normal file storage as well.

In fact: Simply using standard volumes will probably be faster than adding another remote layer with S3, but just saying.

Option 2: S3 Storage 👉🏾 Self-Hosted minio

This approach works the same way for all S3 compatible storages, in my case, I just want to show you how easy it is to create one that is self-hosted. Surely, you can use AWS S3 as well.

Create a new Server (we will call it supa-storage for now) on the Provider of your choice (mine -> Hetzner Cloud) with Docker. Most Providers have Servers with Docker preinstalled. If not, simply go with Ubuntu and install Docker (I won't cover the installation of Docker).

Step 1: Create a docker-compose.yml file as follows

version: '3.8'
services:
  minio:
    image: quay.io/minio/minio
    container_name: minio
    volumes:
      - ./minio-data:/data
    environment:
      MINIO_ROOT_USER: your_root_user
      MINIO_ROOT_PASSWORD: your_root_password
      MINIO_SERVER_URL: https://storage.yourdomain.com
    command: server /data --console-address ":9090"
  nginx:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./nginx-data:/data
      - ./nginx-letsencrypt:/etc/letsencrypt

Run it

docker compose up -d

Manage nginx

Now wait until the containers are started. Once everything is started you will want to open http://your-server-ip:81 in your browser. This will open a login window to the nginx proxy manager also called npm (but has nothing to do with npmjs ✌️). You login with admin@example.com and changeme. Once you are logged in you are asked for new credentials, use whatever you want.

The first thing we want to do now is self-protect the proxy manager. Go to Proxy Hosts and click to add a new one. Now, again, you'll need a subdomain to do that: Like proxy.your-domain.com which points to your server.

Then you can enter in the form proxy.yourdomain.com, you leave scheme as http (yes, not https!), as hostname you enter 127.0.0.1 and choose Port 81 and switch on "Block Common Exploits" and in the SSL tab you choose "Request a new certificate" and tick "Force SSL", "HTTP/2" and "HSTS enabled".

Kinda like this

Now you can go and open proxy.yourdomain.com in the browser and you'll have the same thing but protected. Okay, nice.

Secure minio

Within the proxy manager you want to add 2 hosts for minio.

1. Storage Host: Nearly the same settings as above but this time Domain=storage.yourdomain.com, hostname=minio, port=9000 and also activate Websocket Support. Also add the following in the Advanced Tab:

    # Allow special characters in headers
    ignore_invalid_headers off;
    # Allow any size file to be uploaded.
    # Set to a value such as 1000m; to restrict file size to a specific value
    client_max_body_size 0;
    # Disable buffering
    proxy_buffering off;
    proxy_request_buffering off;
   

   (yeah it is normal that when you visit in the browser you get an error)

2. Dashboard Host: Same as before but hostname=storage-dashboard.yourdomain.com and port=9090 and nothing in the Advanced Tab.

Now you can visit storage-dashboard.yourdomain.com and login with the credentials from what you provided in the docker-compose.yml

Prove that minio is working

Login to minio Dashboard and go to Buckets and create a new bucket mytestbucket. Then go to Object Browser -> mytestbucket and try uploading any file. Worked? Nice!

Get your S3 Credentials from minio for Supabase

Go to Access Keys and click on Create Access Key. Write down both the Access and the Secret Key. You will need it soon.

Take the minio Dashboard offline

Now after setting it up you don't need the Dashboard anymore. You can disable it's public access in your proxy manager by simply clicking disable. You can reactivate it anytime.

2. Setting up the Supabase Server

Create a new Server Instance - do not reuse your S3 server for that (if you have that. If you don't have an S3 Server: you're all set with 1 server instance).

First things first:

1. Log in to that server and run git clone --depth 1 https://github.com/supabase/supabase .

2. cd supabase/docker

3. cp docker-compose.yml docker-compose.yml.bkp (just so you have a backup file to compare)

4. cp .env.example .env

Secure the Kong API Gateway:

Search for the kong: section in docker-compose.yml and get rid of the ports: in there.

Do not route Supabase Studio (Dashboard) with Kong

Go to docker/volumes/api/kong.yml and scroll down where it says "Protected Dashboard" . Remove that whole part of - dashboard. Yes, everything. We do not want kong to route there.

Add nginx and authelia to Supabase

In your docker-compose.yml go to the top where it says services: . From there want to add 2 additional services: authelia and nginx Proxy Manager.

Please note: If you are fine with protecting Supabase Dashboard with HTTPS + Basic Auth (which is completely fine) then you don't need to add authelia and can also skip all of the authelia setup later as you can simply activate Basic Auth with the Proxy Manager. But if you wanna be more flexible in auth terms, e.g. multi-factor, then authelia is for you!

Adapt the docker-compose.yml file with these 2 additional services:

authelia:
  container_name: authelia
  image: authelia/authelia
  restart: unless-stopped
  expose:
    - 9091
  volumes:
    - ./authelia/config:/config
  environment:
    TZ: 'Europe/Berlin'

nginx:
  image: 'jc21/nginx-proxy-manager:latest'
  restart: unless-stopped
  ports:
    # These ports are in format <host-port>:<container-port>
    - '80:80' # Public HTTP Port
    - '443:443' # Public HTTPS Port
    - '81:81' # Admin Web Port
  volumes:
    - ./nginx-data:/data
    - ./nginx-letsencrypt:/etc/letsencrypt
    - ./nginx-snippets:/snippets:ro
  environment:
    TZ: 'Europe/Berlin'

We will configure authelia later, first we continue with the Supabase Config.

Configure your custom S3

You can skip this if you don't have S3.

Go to docker-compose.yml, search for storage and go to its environment definitions.

environment:
    # ...other definitions
    STORAGE_BACKEND: s3
    GLOBAL_S3_BUCKET: supabase
    GLOBAL_S3_ENDPOINT: https://storage.yourdomain.com
    GLOBAL_S3_PROTOCOL: https 
    REGION: eu-south #whatever your region is
    AWS_DEFAULT_REGION: eu-south

    #this next one seems important for minio
    GLOBAL_S3_FORCE_PATH_STYLE: true
    AWS_ACCESS_KEY_ID: your_s3_access_key
    AWS_SECRET_ACCESS_KEY: your_secret_s3_access_key

If you do not use S3

You might (or not) want to change the path where files are stored. See volumes: section in docker-compose.yml -> storage.volumes

Configure Credentials:

Go to your .env file.

1. Set POSTGRES_PASSWORD=some-very-complicated-database-password

2. Generate and set random JWT_SECRET=... with node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

3. Us the self-hosting Guide on supabase.com (https://supabase.com/docs/guides/self-hosting/docker#generate-api-keys) to generate ANON_KEY= and SERVICE_ROLE_KEY= with your JWT_SECRET and set both in your .env

4. Make sure to also set proper keys for LOGFLARE_LOGGER_BACKEND_API_KEY= and LOGFLARE_API_KEY= (I think they are the same but if anyone else from the Supabase Team or so knows better: Tell me)

Configure Studio and API:

Go to your .env file again.

1. Set API_EXTERNAL_URL=your-api.yourdomain.com to whatever you want it to be. This is where all Supabase API requests can and will be sent.

2. Set SUPABASE_PUBLIC_URL=your-api.yourdomain.com to wherever you want to access the Dashboard.

Configure your Page:

As always you'll have an app using Supabase. Now that app is running somewhere. And that somewhere we need to configure. Upfront: You can change that later by simply adapting the env variables and restarting the container (see Section 6).

SITE_URL=https://yourapp.com

# use whatever additional urls you need
ADDITIONAL_REDIRECT_URLS=http://localhost:3000,http://localhost:6000

Configure Postgres Access

If you want to access the Database directly, from the outside, then you simply have to remove the 127.0.0.1 from the docker-compose-yml -> db.ports: section

Configure E-Mail:

I won't cover this in detail as it's not helpful for this specific guide and not required. Simply search for email or SMTP in the .env file. You don't even need to configure that, not even in production - if you are anyways generating mails on your own (which most production sites do).

3. Starting the Supabase + nginx Server

Since we did the whole configuration part already and since we removed Supabases default security holes we can now start all containers:

1. docker compose pull

2. docker compose up -d

Wait for all containers to have started and check if everything is running fine with docker ps -> if any of the containers says something like Restarted X Seconds ago it is most likely that there's some failure happening. Unusual with my setup though 🫶🏾.

4. Make it run!

The containers are running but Supabase isn't accessible - yet. However, our nginx proxy is!

1. Protect the Proxy with itself first, see Section 3.2 where this was already explained including the initial credentials

2. Now go to your protected proxy on e.g. supabase-proxy.yourdomain.com

3. Setup the API Proxy: Add a new proxy with your-api.your domain.com, scheme=http, hostname=kong , port=8000 . Activate Websocket Support and in the SSL Tab request new certificate and activate all checkboxes

4. Setup the Dashboard Proxy:

   1. Same as API Proxy but with studio.yourdomain.com and this time use hostname=studio , port=3000 .

   2. Since Studio accesses the storage and auth service directly we need to go to the Custom Locations and (Update: Don't do this in Custom Locations Tab as this will not forward everything we need) make sure that the path /storage and /auth is forwarded to hostname=kong and port=8000 instead and we also need to make sure that Authorization (if later enabled) is always passed downwards.

      How? Easy: Go to Advanced Tab and configure this:

       location / {
         proxy_set_header  Authorization $http_authorization;
         proxy_pass_header Authorization;
         proxy_pass $forward_scheme://studio:3000;
       }
      
       location /storage {
         proxy_set_header  Authorization $http_authorization;
         proxy_pass_header Authorization;
         proxy_pass $forward_scheme://kong:8000;
       }
      
       location /auth {
         proxy_set_header  Authorization $http_authorization;
         proxy_pass_header Authorization;
         proxy_pass $forward_scheme://kong:8000;
      

}

    3. When both done: Save it.

Now your Supabase Studio should be publicly accessible under studio.yourdomain.com / without Protection though - yet.

Basic Auth

As stated above, you can simply use Basic Auth now and later on upgrade to some more sophisticated stuff like authelia (no issue in upgrading later). To do that, go to Access Lists in the proxy manager, create a new one, give it any name, check Satisfy Any, go to Authorization Tab and enter the username/password combo you'd like.

Now go to your Proxy Host studio... and click edit and select your created Access List there. Save it.

When you now visit studio.yourdomain.com it will be protected and ask for username/pass.

Just a sidenote: You could stop at this point

Like, for real. You are having a full-fledged self-hosted setup already. Felt complex, wasn't all too complex in the end, was it?

5. More than Basic Auth: Authelia

Authelia is another Layer running in between nginx to protect specific routes with Authentication - and Authelia can do Multi-Factor, if you want that.

This isn't extremely intuitive, but rather unusually complex. However only if you don't know how to do that. Now since I've put in all the work of researching you can just simply copy and paste. So yeah, I've done it for you.

We want to get rid of our Basic Authentication for Supabase Studio and instead have a nice-looking login screen.

We already installed authelia as part of our Stack (check the docker-compose.yml above) 😎. So we only need to configure it now.

5.1 Adapt the Default Configuration

Open up the file authelia/config/configuration.yml and if you want, you can empty it because we will only use a small portion of it to get started (you can dig deeper into the config in their documentation).

This is my initial config to get started (search for yourdomain.com to see the things you have to change and please also go through it for changing secrets before you actually go to production):

## The theme to display: light, dark, grey, auto.
theme: light

## The secret used to generate JWT tokens when validating user identity by email confirmation. JWT Secret can also be
## set using a secret: https://www.authelia.com/c/secrets
jwt_secret: a_very_important_secret

default_redirection_url: https://google.com # confusing haxxors
default_2fa_method: ""

server:
  host: 0.0.0.0
  port: 9091
  path: ""
  enable_pprof: false
  enable_expvars: false
  disable_healthcheck: false
  read_buffer_size: 4096
  write_buffer_size: 4096

  ## Server headers configuration/customization.
  headers:
    ## The CSP Template. Read the docs.
    csp_template: ""

  ## Authelia by default doesn't accept TLS communication on the server port. This section overrides this behaviour.
  tls:
    key: ""
    certificate: ""
    client_certificates: []

log:
  level: debug

totp:
  issuer: yourdomain.com #your authelia top-level domain
  period: 30
  digits: 6
  algorithm: sha1
  skew: 1

authentication_backend:
  file:
    path: /config/users_database.yml
    watch: false
    search:
      email: false
      case_insensitive: false
    password:
      algorithm: argon2
      argon2:
        variant: argon2id
        iterations: 3
        memory: 65536
        parallelism: 4
        key_length: 32
        salt_length: 16
  ## Password Reset Options.
  password_reset:
    ## Disable both the HTML element and the API for reset password functionality.
    disable: false
    ## External reset password url that redirects the user to an external reset portal. This disables the internal reset
    ## functionality.
    custom_url: ""
  refresh_interval: 5m


password_policy:
  ## The standard policy allows you to tune individual settings manually.
  standard:
    enabled: false
    min_length: 8
    max_length: 0
    require_uppercase: true
    require_lowercase: true
    require_number: true
    require_special: true

  ## zxcvbn is a well known and used password strength algorithm. It does not have tunable settings.
  zxcvbn:
    enabled: false
    min_score: 3


access_control:
  ## Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'. It is the policy applied to any
  ## resource if there is no policy to be applied to the user.
  default_policy: deny
  rules:
    - domain:
        - "auth.yourdomain.com"
      policy: bypass
    - domain: "studio.yourdomain.com"
      policy: one_factor

session:
  ## The name of the session cookie.
  name: authelia_session
  domain: yourdomain.com
  ## https://www.authelia.com/c/session#same_site
  same_site: lax

  ## The secret to encrypt the session data. 
  ## This is only used with Redis / Redis Sentinel.
  secret: insecure_session_secret
  ## The time before the cookie expires and the session is destroyed if remember me IS NOT selected.
  expiration: 1h
  ## The inactivity time before the session is reset. If expiration is set to 1h, and this is set to 5m, if the user
  ## does not select the remember me option their session will get destroyed after 1h, or after 5m since the last time
  ## Authelia detected user activity.
  inactivity: 5m
  ## The time before the cookie expires and the session is destroyed if remember me IS selected.
  ## Value of -1 disables remember me.
  remember_me_duration: 1M

# security measures against hackers
regulation:
  max_retries: 3
  find_time: 2m
  ban_time: 30m

storage:
  encryption_key: a_very_important_secret
  local:
    path: /config/db.sqlite3

notifier:
  disable_startup_check: false
  ## File System (Notification Provider)
  filesystem:
    filename: /config/notification.txt

Restart authelia with docker compose stop authelia and docker compose up -d --force-recreate authelia .

5.2 Configure your users:

In the authelia/config folder you should find now a users_database.yml file.

Open it and you'll find a username (authelia) with a password (also authelia but encrypted with argon2). So if you want to change it, you need to replace those in that file and restart authelia container again. I'll leave it for now with username=authelia/pw=authelia .

5.3 Configure reusable snippets

On your actual server you should see ./nginx-data folder as well as ./nginx-letsencrypt folder in your supabase/docker directory. Now create a new directory next to those with the name nginx-snippets .

Now in this directory you create 2 files (note that in the second file we use auth.yourdomain.com which must be whatever you wanna use):

nginx-snippets/authelia-location.conf

# File: nginx-snippets/authelia-location.conf

set $upstream_authelia http://authelia:9091/api/verify;

## Virtual endpoint created by nginx to forward auth requests.
location /authelia {
    ## Essential Proxy Configuration
    internal;
    proxy_pass $upstream_authelia;

    ## Headers
    ## The headers starting with X-* are required.
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Original-Method $request_method;
    proxy_set_header X-Forwarded-Method $request_method;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Content-Length "";
    proxy_set_header Connection "";

    ## Basic Proxy Configuration
    proxy_pass_request_body off;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; # Timeout if the real server is dead
    proxy_redirect http:// $scheme://;
    proxy_http_version 1.1;
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
    proxy_buffers 4 32k;
    client_body_buffer_size 128k;

    ## Advanced Proxy Configuration
    send_timeout 5m;
    proxy_read_timeout 240;
    proxy_send_timeout 240;
    proxy_connect_timeout 240;
}

nginx-snippets/authelia-authrequest.conf

# File: nginx-snippets/authelia-authrequest.conf

## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /authelia;

## Set the $target_url variable based on the original request.

## Comment this line if you're using nginx without the http_set_misc module.
set_escape_uri $target_url $scheme://$http_host$request_uri;

## Uncomment this line if you're using NGINX without the http_set_misc module.
# set $target_url $scheme://$http_host$request_uri;

## Save the upstream response headers from Authelia to variables.
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
auth_request_set $name $upstream_http_remote_name;
auth_request_set $email $upstream_http_remote_email;

## Inject the response headers from the variables into the request made to the backend.
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
proxy_set_header Remote-Name $name;
proxy_set_header Remote-Email $email;

## If the subreqest returns 200 pass to the backend, if the subrequest returns 401 redirect to the portal.
error_page 401 =302 https://auth.yourdomain.com/?rd=$target_url;

nginx-snippets/proxy.conf

## Headers
proxy_set_header Host $host;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Connection "";

## Basic Proxy Configuration
client_body_buffer_size 128k;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; ## Timeout if the real server is dead.
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 64 256k;

## Trusted Proxies Configuration
# The next line is very much recommended for security reasons!
# It works without the line but this would reduce security.
# So what is it and WHICH ip to set here?
# Basically you wanna set here the subnet your docker network is using here.
# The default subnet is 172.17.0.0/16 HOWEVER in my case
# this isn't true and probably for you as well:
# Check the ip-adress of your container with docker inspect container_id
# all of your containers in this stack probably 
# have something like 172.x.x.x
# now basically put 2 zeros at the end and /16 and you have your subnet.
# in my case that was one container with '172.20.0.11'
# so it is 172.20.0.0/16
# ------
# set_real_ip_from 172.17.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

## Advanced Proxy Configuration
send_timeout 5m;
proxy_read_timeout 360;
proxy_send_timeout 360;
proxy_connect_timeout 360;

When you have added those snippets then do docker compose stop authelia && docker compose up -d --force-recreate authelia .

5.4 Setup the Auth Portal

Go to your proxy manager web interface and add a new proxy host. This time hostname=authelia and port=9091. Activate "Block Common Exploits" and "Websockets Support", activate all Checkboxes in SSL Tab. Then go to "Advanced" Tab and add this:

location / {
    include /snippets/proxy.conf;
    proxy_pass $forward_scheme://$server:$port;
}

Done. You should be able to test it with your username/password (authelia/authelia if you haven't changed it yet.)

5.5 Setup Studio to use Authelia

Edit your Supabase Studio Proxy Host and remove Basic Auth by choosing "Publicly Accessible" in the Access List (you can also leave it on but I haven't tried if double protection brings problems). Go to the advanced tab and add this:

include /snippets/authelia-location.conf;

location / {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://$server:$port;
}

location /storage {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://kong:8000;
}

location /auth {
    include /snippets/proxy.conf;
    include /snippets/authelia-authrequest.conf;
    proxy_pass $forward_scheme://kong:8000;
}

Done. Save it, load Studio and now Authelia protects your Studio. 🎉🤩

6. Changing configuration in a running environment

Sometimes you need to just update values, such as when you e.g. updated the Postgres password or needed to change some url config. In that case you can bring the containers down with docker compose down (no worries, since we are using volumes, all data is kept) and then you can do docker compose up -d again loading the updated config.

If you liked that, consider buying me a coffee ❤️ ko-fi.com/activenode

What is Design for Failure

DFF is a principle that applies to the UI and the Code part likewise: Make sure errors are handled. This principle doesn't originate in Software. Let me give you an example from the automotive sector: It is an option in cars to mechanically decouple your steering wheel so you don't interfere with the driving assistant. Now that sounds scary until you understand how it works: It can only decouple as long as the electronic assistant is alive. If the assistant doesn't work for whatever reason the permanent signal that's holding back (!) the steering wheel is interrupted and the wheel naturally snaps back into place - this is Design for Failure. It doesn't matter why it fails, the only thing that matters is getting control over the car.

My Vacuum Robot had bad DFF

I don't like being spied on sitting on the toilet. You don't have to be paranoid, you just have to be realistic. Especially as a Programmer, you should know that things that can spy you will spy on you - every big company has been hacked and they will be in the future. Nowadays I own a Valetudo-based robot - it's awesome ❤️.

However, before that, I owned an expensive Vacuum Robot from a green, german brand claiming to have proper data protection (and especially not a camera built-in but lasers).

That thing's Error Design drove me nuts - and I mean that. I've even written the company multiple E-Mails offering them consultancy in Software Architecture but I eventually gave up and they didn't even respond to my last mail. It was the definition of "Hardware that is causing Mental Health Problems".

From a coding perspective it was clear that it had to follow some kind of logic like this:

if (SENSOR_BOX_FULL) {
  print "Please clean the container"
} else if (SENSOR_LASER_BLOCKED) {
  print "Something is blocking the laser"
}
// else if ........ whatever 
else {
  // finally, the catch-it-all-case!
  print "I am stuck"
}

That meant that every time there was an error that wasn't specific enough it just said something like "I am stuck". Yeah, right. Stuck in what, with what? Definitely not stuck-stuck because it is free roaming on the floor.

Imagine this company would build manned space rockets and there is a leak with massive pressure loss: "Space Rocket is stuck".

It gets worse: The Notifications shown on the Smartphone apparently weren't using the same code logic as the App Code (like wtf?). That meant: My Notification Center showed different error messages than when clicking on it (which opens the App) e.g.

• Notification Center: Clean the Brush

• App: I am stuck

Needless to say that the brush was new and that it wasn't stuck. I've checked every single micrometer of that piece of ****.

Okay but where are you going with this Vacuum Sample David?

Error messages are supposed to help. They are not necessarily supposed to solve a problem. E.g.: If your internet is down it will not solve your problem knowing that it is down. Or if you have wrong pressure in your space rocket it will also not solve the problem by telling you so. But it will help you trying out the right things and calling the right people.

This also means: If an error cannot be exactly narrowed down to be exactly one thing you must provide enough details - even if they won't help solving the problem immediately. Even if that means showing "Error X1230900 Stack Overflow In Line 33:20". Because even if this reads obscure it is way more helpful than a robot telling you "I am stuck" even though it is not stuck. With the obscure message you can at least tell support the exact error message and they will be able to follow up.

There is a pretty clear path on how to design for errors

From my own experience, there are 3 (4) essential types and I will show the software design in human-readable samples.

1. Recoverable Errors: The Vacuum Robot can't clean anymore because the box is full of dirt. This is solvable by emptying the box. The Software should do a couple of things here:

   • Notify on the App ("Clean Me")

   • Wait a reasonable amount of time in place (e.g. 5-8 Minutes) to let the person empty the box.

     Expect the person not to be at home and provide a fallback after the waiting time for the robot to drive back to the station with a full box. This is super-useful because the Robot won't run out of battery and will be ready to continue once the box is emptied.

   • The aforementioned means also saving the position where the robot was and how much it cleaned right before it drove back to the station.

   • In Web applications recoverable errors go hand in hand with good UI Design: Couldn't save data? Don't ask the user to retry. Auto-retry 2 to 3 times before annoying the user and if it still fails tell the user (but then it falls into the definition of 2/3).

2. Unrecoverable but known Errors: Your coffee machine detects that there is water in the water tank but it can't pull water:

   • Assuming there is LCD but no App for the Coffee Machine: Give exact error code.

   • There is no display? No problem. There certainly are some LEDs somewhere. Abuse one/or more to give indications about the error (e.g. 2 LEDs are permanently blinking)

3. Unknown Errors: In our interconnected world it can very well be that your software cannot determine the exact error why something isn't working. When I am building Software as a Service it will most likely use an external provider for Login (e.g. Auth0, Pocketbase, Supabase, ...). Now often such providers again use themselves providers e.g. for hosting data or for connecting to other services (Apple Login, Google Login, ...). So we have a lot of potential places that could fail.

   There is a simple solution to handle these errors: Your task is to be able to help identifying the issue. This is why it's crucial that your software logs actions to some kind of log-store of what happened until and including the error e.g.

   1. log(loginUserData, currentTime())

   2. log('Clicked on Start', currentTime())

   3. log('Caught Error, could'nt start, Error, currentTime())

Now some people argue: But what if the internet connection is down and you cannot send logs to the server? You don't have to! At the point of error happening you show a modal to the user which says something like:  
"Copy this message and send it to support."

The user doesn't care. The user just wants help and the user will get help by contacting you with the full error log. We implemented this in a way that "hides" this from non-technical users by using `base64` encoding which comes down to something like copying `=YWZkcztmZGF...` (simply do not confuse the user with an interpretation of messages)

1. Errors that aren't errors: When I opened the lid to clean the box, my vacuum cleaner gave constant annoying beeps. Same when I simply tried to move it to a different place in idle mode. Try to think of a more common sample: Cars. Now imagine when you open the car door the car starts to tell you in very annoying ways that the door is open - Once you open the door: BEEP BEEP. Even if you're just loading or unloading it - it will constantly beep. That makes total sense when I'm trying to drive but not when it's parked. So stop trying to make error handling where error handling isn't needed in the first place. If you feel like you missed something: Give a beta out to real users - #usertests.

The Misconception of catching errors

There is a misconception out there: Developers think they have to catch errors and then "gracefully continue" in whichever way - I don't know where people learn this but this doesn't make sense.

A concept that is available in many languages is try-catch . Check this pseudo code:

try {
  basically.all.your.software.runs.here
} catch (Error) { // <- this "Error" contains information about what happened (e.g. "Server Error 503")
  whoopsie.something.bad.happened
}

It makes sure that your application doesn't just quit of failure - which would be even worse because then you cannot do any kind of error handling anymore.

However, inside this catch requires you to consider one of the 3 error scenarios from above. So e.g.:

try {
  // ... blabla
} catch (Error) {
    showErrorDialogToUserSoUserCanCopyPasteAndMailMe(Error);
}

This isn't as obvious as you think

Some developers would think now: That's very obvious ain't it? If you think so then please go back to your code and tell me if you handle the error or if you try to gracefully overgo it. Because the latter one is what I usually see. And this is really bad as it implies covering errors until errors happen that are even worse.

Let me give you a sample:

let someData;
try {
  someData = loadSomeDataFromServer();
} catch {
  someData = []; // empty data
}

This is bad. Any error happening in your try block will just be gracefully caught and you continue the application. To put it very clearly: This is the exact same thing as when you have a massive leak in your roof and every time it rains you have a lot of water in your room and the only thing you do is removing the water every single time.

The application will still work because you provide it with fallback data. Now where's the benefit for the user? The error is not resolved and the data is empty. How is the user benefiting from empty data (which also makes the application unusable) rather than an error that will at least let the user know why the app is unusable.

The Misconception of Fallback Data

Bad UX is when you gracefully, silently catch errors because then the user is even more confused about why the app isn't working properly.

I also want to give you another perspective here: Setting default fallbacks with good intentions (shadowing errors that should be errors) can be very harmful and time-consuming. Imagine a few people leaving the company, some new people joining, things seem to work fine, and people start working on the project. They run it on the internal servers: All good.

Now things are supposed to go to production: Nothing works. For the internal servers it worked because somewhere in the project there is a file with something like

if (not(config)) {
  // fallback
  config = someDefaultConfigThatOnlyWorksOnInternalServers
}

If you don't have that fallback it would be a more consistent solution: Defining configs per environment. And people would know and learn very early on because it's the same requirement on all Environments, no matter if Production or not.

And now comes the worst part about fallbacks: Partial (unintended) fallbacks. I had that in my own project and it's a severe problem: You set-up your config but you missed 1 value. Congratulations, now you have fallback values mixed up with Production.

Conclusion

Let your software break. It must break. Things must break to be able to get them fixed. Yeah, let that sink in. And that doesn't imply at all that it will be a painful experience for the user. Humans deal with errors all their life. But in the non-technical era they hadn't had as much frustrating errors. Your bed broke? Not cool but the error is clear: It's broken. Your pencil is dried out? That's a clear one as well. Water Pipe clogged? Call a plumber.

But Website says "Something wen't wrong, please try again" is the most frustrating thing as there is not a single thing the user is able to do. The user can't give you detailed error information, the user doesn't know if it makes sense to restart/reload, the user knows nothing and is indeed psychologically frozen in that state which can cause extreme frustration.

Dusk

The year started with a depressive phase in the switch from 2021 to 2022. I was extremely unhappy in my job back then as I didn't agree with the management mindset. The salary was reasonably good, above average. I got employed as a Frontend Architect in a FinTech Startup of a Bank. We created indeed great architecture - initially (I know it sounds arrogant but it's important to acknowledge good outcomes) and there were a lot of cool things to learn (e.g. from the Backend Architects which I've worked with 🤝). But very clearly when most of the base was considered "done" we moved to the "we should get done ASAP" mindset.

Eventually, my profession moved from being the Architect to ensuring things get done fast and also making sure to code a lot to get things done faster.

This state of seeing the architecture, quality and consistency loosening up whilst not being able to do what I was hired for due to artificially induced time pressure moved me into a state of a well-payed puppet. My opinion didn't matter anymore. Not because people argued against it - but simply because the setup enforced it and there was no room for critical opinions.

I did talk to my boss about being extremely unhappy. I'm not sure if he got the message back then, I felt I communicated very clearly about what I thought I was hired for.

At this time the only thing that gave me happiness was my girlfriend and my side project of "Becoming a Teacher/Mentor somehow" which I kicked off in 2021 with my first official LinkedIn Learning Courses 🎉.

The night glooms

I quit my FinTech job in Late 2021 but due to contractual agreements, I was only free in April 2022.

It's not perfect anywhere, that's for sure. But after having seen several big players, the latter 2 being automotive and FinTech and having realized that in many of those it isn't about actually making good stuff but it's about making stuff just good enough to make sure a few individuals get a big bonus I felt senseless. Even if you want to make awesome things you'll soon realize that the walls you have to break are not just a few meters thick - rather a few kilometers - you spend more time breaking walls than building things.

I felt enslaved by money-driven companies. Don't get me wrong: It's not that I put disgrace on companies targeting making money - it's the order of priorities. If you go back a few decades you will notice the massive shift from "a product brings massive money because it's a good product" to "a product sells even when it shouldn't because I did a good job in lying". You might call it "marketing". I call bullsh**t and a loss of ethics. And psychology proves that you get unhappy over time if you feel senselessness. More and more money will become your painkiller for unhappiness. Yet, that's not just for products. That's the same for how bigger companies internally work: Just make sure to twist the numbers correctly so that it looks like your company does great.

👉🏾 In the first quarter of 2022 I prepared myself for going back to freelance.

I applied at Toptal and was accepted. I was told I've made great impressions on the talent scouts - not sure if they tell that to everybody accepted but it was indeed helping my motivation.

Additionally, I pinged a few recruiters in my contact list over LinkedIn to let them know I'll be available for freelance jobs.

And I also didn't want to get too narrow-minded excluding myself from good employment options. I had a few standard interviews with some companies as well but none of them checked all my requirements.

There was a short period as well where I was hyped to join https://www.sketch.com/ as I love using the tool ✍️ - the hype turned into disappointment though. The interview process was a bit immature, intransparent and confusing. E.g. they said I should've done certain things in a certain way without discussing my architectural thoughts behind it. And here's something to laugh about: I specifically asked before if the "optional" tasks are really optional or a rabbit hole. They said they are optional but I was punished afterward for not doing them 🫠. There's more but the gist is: Disappointment. Sounds bad but there's some good in it: It stopped me from joining a company in which I might've felt too mature / too advanced. But I wanted to join a company in which I don't have to fight for maturity.

tl;dr: I had quite some calls in the first quarter of 2022 - either for employment or freelance. None of them I'd call out wasted time. All of them were helping to see and realize what I want and what I don't - and the latter one is extremely important.

I can see Sparkles at the Horizon

Toptal is more than just a Freelancing platform. There is a Slack community with thousands of people. I wanted to get inspired and started to post on some channels that I'm new and that I would like to have remote calls with random people - just to chat.

I think ~4 people were open to it. All of those were indeed nice chats and it's always interesting to hear about the life and work of other people.

With one I kinda got something like a friendship and we decided to make a combo version (v2, in the making) of my short stories Book. V1: Developer Stories From Hell - so yet another funny side project 🎉.

With all of the calls, and all of the thoughts it became pretty clear that freelance will be my way to go (but read on!).

In one of the calls in February, I was in touch with a University looking for employees to work on their internal Software. They were nice but I felt it isn't a fit for me at that moment. However: I told them if they are searching for freelance adjunct professors I'd be happy to lecture - especially if they got remote options.

In March I saw a Post on Twitter. It said: "If you know React and are open for a job contact me - if you're not an asshole". Ah, how I loved that. Direct, yet funny!

I got in touch with that guy (👋 Pepo from Wahnsinn GmbH) and we had a call. He was cool, the chat was extremely uncomplicated. He judged me by character instead of by "How many space rockets fit into a bus?" and eventually said something like "I like you, next we would set up a call with our boss if you'd like?". "Sure", I said.

Worth mentioning I've worked more and more with Supabase at that point in time. I think I was one of the very early users when it was still in Beta. I've even written a lot of issues of which the most important ones are resolved as of today.

Plus, somewhere in between all of that, I got in touch with Paul Copplestone (the CEO from Supabase, btw. very nice Podcast Episode here: https://open.spotify.com/episode/0RwPlcpIR8tSqqv8Y9o898?si=391ab30d53a04859).

Being a very early adopter and convinced of Supabase I would've loved to become a Developer Advocate. Paul indicated that they'd love to but want to grow organically and at that point in time my targeted role was staffed in my timezone already.

The Dawn

My first freelance job ahead of me: At Wahnsinn.

Meanwhile, we're still in the first quarter of 2022, the University got back to me and said that they would have a job as a part-time lecturer for me 🎉. That was perfect because I love doing different things in small packages over monotony hence there would be enough time left to do freelancing.

The second call with Wahnsinn was equally chilled. They made clear that Freelance is an option but that they'd rather have employees. I responded: I can't. I'm burned by being locked in places that force their employees to get SAFE to prove they're agile even though they really are anything but agile. The boss said: "All good, no worries. You do you. We'd love to have you as an employee but you gotta do what fits your needs." That was unusual. Normally, companies are trying to convince you into something even if you state you're not into it - and they normally don't give you the option to do either freelance or being employed. I never felt so much in control about a job decision.

I told them that I wanted to go freelance to have the freedom of also being a teacher on the side and that it helps my overall motivation when I can learn and experiment with other things as well. He said: "That shouldn't be a problem. You'll have a 30-hour job and you can do your other stuff as long as you'll not lose focus on your job." Again: Unusual. Most companies give you some kind of suspicious look. But he was just being honest and expected nothing but honesty from my side.

I got an employment offer (still undecided if I wanna be employed at all) with something that might scare off other people: A 2-week notice period. And I loved it. It shows: That company doesn't want to hold people that do not want to be there. That company tries to hold people by trying to be a good company. And as a developer, I only see the benefits as there are lots of open opportunities in the market.

All of the above made me decide to join the company as an employee 🫢. No one forced me into anything and I said "if they lied or stuff is going nuts I'll be out in 2 weeks." There was not a single feeling of being locked in 🍻.

The Sun rises

When I joined I was put on a React Design System project. I love Design Systems. I've not only read a lot of books and articles about how companies evolve with Design Systems but I've also worked on a lot of them and helped with the implementation of those - not only from a technical but also from a design and organizational perspective.

My motivation was back - I still felt exhausted though. I wanna point that out (!) because many people could trap their thoughts into "Ah okay, David got a cool new job and now he's happy again, all good." It's not like that, so don't even start to think that things change over night 🌝. Things change gradually and that's a hard pill to swallow - for me same as for everybody else.

I loved improving the Design System at work. I revamped a lot of things there. On the side I started a YouTube Channel (https://youtube.com/@activenode), eventually had my first 45mins of lecturing at the university and worked on a side project with Supabase: I've rewritten an existing 9-year-old PHP application with Next.js and Supabase.

Since Supabase centers all of the features around Postgres (a Database System, similar to MySQL) I got even more boost as I just love working with databases features (even though I am primarily a Frontend Architect).

The best thing about that was: I got so much into Next.js and Supabase that we found it to be a perfect stack for one of our company projects. This means (Attention please!): My side project work led to the fact of me becoming a Next.js / Supabase Pro which helped reducing costs in the company project. This is crucial 💪. Too many companies watch your side actions suspiciously because they think it harms them. But in fact, they harm your bond of trust by stalking your actions.

I also moved my blog from dev.to to Hashnode because I could easily set up my custom domain without any fees and the overall UX was much more inviting. It helped me to write more blog posts and it also provides the feeling of not being trapped as I own the domain.

Looking directly into the Sunlight isn't healthy 🥵

Let's recap: Without reflection it felt like "I didn't do much this year". But in fact: Lots of calls, lots of thoughts, 2 LinkedIn Learning Courses (I underestimate the massive amount of hours it takes to have 1 hour of final video all the time), started lecturing at the University, created a YouTube Channel, became a Supabase Expert and helped on the repository, switched to a company as an employee although having everything prepared for going Freelance, mentored 3 people on their journey of becoming developers, improved my information chaos by using Notion actively, coded a lot and learned a lot (too much) of new tech and more...

It sounds like it became a perfect year eventually but there's one thing I didn't do: Put my health at first place. Over the year, I not only had COVID-19 which was a tough one even after being negative but I even had 2 months in winter of getting sick all the time. And at this point of writing, I'm still struggling with the aftereffects of a rough flu. It's getting better every day but it felt like my immune system had to re-initialize after all of the "being mostly at home".

The weird thing is the thoughts that come up:

• Why am I still sick?

• I wanna do stuff.

• My body is annoying.

My doctor said something clever:

"You have to show a little bit more humility to your body. Your telling me that you don't know why you're so tired lately. For me it comes obvious: You've been jumping from one infection to another and the body needs time to regenerate. Not giving it time is not showing enough respect."

Of course, it is very obvious that our body is the most important thing we have and well all know about the well-known facts about doing sports. Still many of us don't. And we only come to realize that when it seems to be too late.

So here I am reflecting that when I ask myself "Can I skip doing Yoga and making sure to just work a little bit more to finish that task?" I will need to always go for the first one. Because you only notice missing out on it when you're in pain. And when you are it's even harder to do so.

One more thing

You might've read my article about my offer from Amazon (https://blog.activenode.de/getting-interviewed-at-amazon). In 2022 I got contacted again by Amazon because I'd made such a good impression the last time. I felt flattered and agreed for interviewing with an even higher position (Level 6). However: This time I didn't get an offer and I was not told exactly why. Unfortunately, it's normal that they don't tell you exact reasons for legal reasons to avoid law suits 🙃. I'm pointing this out because rejection happens on all levels and is part of the process (another good read: https://blog.activenode.de/mastering-frontend-interviews). I felt extremely secure that they'd provide me with an offer but at the end of the day it could've been anything aside from my hard/soft skills e.g. fear of me signing and then going freelance again. I'll never know.

Thanks Hashnode

Thanks for Hashnode for initiating the Dev Retro 2022. I probably wouldn't have reflected if you hadn't brought it up. It is known to be extremely helpful to reflect more often and this one really helps appreciating the year.

In the old days everybody would scream Redux and you'd check with some kind of state property if fetching data was already done or is currently being done. Nowadays we have Redux + a bunch of other options - same goal, different architectures.

The existing stores are awesome, partially damn easy (e.g. zustand) and do work fine.

But (!) stores do not solve side-effect problems

The problem is that within the React Lifecycle you can have the following situation: 3 components need data, hence 3 components make use of your custom hook useData and that hook checks in the store if data is already available e.g. with

// my custom hook
function useData() {
  const data = useZustand(state => state.data);

  useEffect(() => {
    if (!data) {
     fetchData().then(/** some fetching logic **/);
    }
  }, [data]);

  return data;
}

But this is troublesome - and I am unfortunately seeing this more and more on websites: The data is being fetched multiple times, multiple requests are sent. The reason is easier explained by providing some visual help in the following diagram:

All components are using the hook useData(). And useData in that lifecycle will have empty state data. Still the useEffect() of useData() will be called 3 times as we have 3 components using it - reminder: Reused hooks are not Singletons. And the problem continues: You cannot really check the provided state data as you get the state of this lifecycle so another component might've called the fetching function but the other components will be notified in the next lifecycle run and hence also trigger fetching the data.

This is not a React problem

Now it might sound like "Isn't this bad as per architecture?". No. You get a state per lifecycle across your components such that all components will have the same, in-sync-state which is required for your components not to behave weird.

It's your problem: You need to orchestrate

At the end of the day you have to avoid that functions running outside of the React lifecycle (such as data fetching methods) will be ran multiple times. This is possible with all major State Management Libraries because they do update the state before components get notified.

E.g. in Redux (with redux-thunk) you'd have your reducer something like:

dispatch((dispatch, getState) => {
  if (getState().isFetchingData === false) {
    fetchData().then(data => dispatch({
      action: 'UPDATE_DATA', payload: data
    }));
  }
});

or in zustand you could build it like this:

const store = create((set, get) => ({
  isFetchingData: false,
  fetchData: () => {
   if (get().isFetchingData === false) {
     fetchData().then(data => set({data}));
   }
  }
}));

Works but also is additional if-overhead - and you have to remember to do it.

unglitch provides Lock-or-Leave calls

I wanted a simple state management solving that problem. I could've adapted zustand but then I went with digging into building an even simpler system: unglitch.

unglitch is pretty similiar to zustand and it kinda uses the same technology. However built-in with the State Management do come locked calls.

It's easiest explained with the following code snippet:

import { useStore, update } from './my-store';

const fetchData(releaseLock: () => void, realtimeData) {
  // we can check the live data outside of the lifecycle  
  if (realtimeData === null) {
    // ..fetch some data...
    // ...then update it:
    update({ data: [/** your data here */]});

    // release the lock so it can be called again
    releaseLock();
  }  
}
fetchData.LOCK_TOKEN = "FETCH_DATA";


const useData = () => {
  const [data, lockedCall] = useStore(state => state.data);

  useEffect(() => {
   lockedCall(fetchData);
  }, []); 

  return data;
}

The LOCK_TOKEN is grabbed automatically when you run the lockedCall. If the LOCK_TOKEN is not present you will be facing an error so don't worry about forgetting it. Sure, you could still manually call that function but as long as you run lockedCall it will take care of running it only once.

The function that is being called always receives a function as first parameter that will free the lock again and the second parameter is exactly the provided state data in useStore so here it is state.data. The difference is however: The function that is being called receives the realtimeData and not the data that is currently available in the lifecycle. This allows you to check if you need to fetch data or not.

Besides this lock mechanism the store works pretty much similiar to zustand. Check it out.

Is the Tablet too limited for doing any kind of work?

Well that's what we are going to evaluate. One thing is for sure: It always depends ... but I was more than amazed what was possible when finally things were running smooth.

First of all: No one needs a Tablet if you got a Laptop. I bought one for several reasons: Still lighter (12 inch, 567g) and thinner than basically any Laptop, fits even in the smallest places and runs the on-the-go Apps such as Netflix, Prime, etc. natively. So it can be a pretty cool mobile device, especially when you have a keyboard cover with it. Also I can just grab it and leave. As opposed to my Laptop which is at my desk connected with multiple cables and annoying to reattach honestly.

So tl;dr: It's more convenient to have a device laying around ready-to-go rather than grabbing a Laptop, its protection and potentially forgetting to bring the charger. With the tablet I can use my Smartphone charger as well.

Now this was a trip longer than a week and I was kinda scared of the experiment of not bringing a fully-equipped, terminal-running laptop that I am used to but you gotta experiment to find out.

The Hardware

In this Post I'm referring to my Samsung Tablet S8+, 12 inch (due to its 16:10 form factor it feels rather like an 11 inch iPad). This helps yourself to compare to tablets with weaker specs.

At work I use a 14 inch Macbook Pro.

Here's how it went, 10 days no Laptop

General Usage (Ergonomics)

• Train, Bus, Plane, etc. are environments that do not have a lot of space. Using the Tablet here is pretty easy. However comparing it to a small laptop (~13 inch) it still looses the comparison because the Tablet is not as adjustable in it's position as the laptop (adjusting the tablet is dependent on the cover and the original keyboard cover from Samsung only has one position). But still, pretty solid and the tablet wins space-wise.

• With a thin keyboard cover comes a thin keyboard. That however was surprisingly good. Sure you can't compare it to a MacBook Keyboard or even my Keychron. However I was surprised how good it felt because I expected somehow way less. Benefit: Pretty silent so you won't annoy anyone sitting next to you. So keyboard-wise it's pretty solid as well. And honestly if you bringing a clicky Keyboard on the Bus, Train or Plane is annoying everyone else anyway.

• Bring a Mouse: On the train you won't need the mouse. The Pen is really awesome to click stuff and move the cursor to different places. It even supports hovering if you're roundabout 1inch from the tablet away which is neat. But if you wanna have a real comfortable session where enough room is provided the mouse will definitely light up your day, that's a promise.

Working with Direct Sunlight: Temperature and Readability

Apparently the Tab S8+ seems to go with 420nits Brightness. As a comparison: Most normal monitors go around 250/300 nits, the iPad Pro comes with 600 Nits and the Macbook Pro 2021+ at its peak can have more than 1000nits - compared to that 420 seems to be low for a Highend Tablet, but read yourself:

• The good news is: You can kinda still work in direct, non-cloudy sunlight with the Samsung Tablet. But it comes with 2 downsides: It's really exhausting for your eyes and the Tablet will randomly close Apps if it gets really hot (and it does get hot in Summer). I would rather have the tablet stopping to work and telling me to go somewhere else rather than deciding for me to close Apps (mostly Chrome) which I found extremely patronising.

• I compared it to an iPad Pro from someone else and the brightness in direct sunlight with the iPad is a huge benefit compared to my tablet (this difference however is barely noticeable in normal, shaded environments).

Screen Resolution / Multi-Window

• The Screen Resolution was really good for getting things done. I had a Gitpod window at kinda 70% of screen width and then below and aside another Browser Window at 60-70% as well.

Samsungs Tablet has 2 Working Modes: Normal Tablet Mode and the Samsung DeX (=Desktop) Mode. The latter one has a desktop-like look, a higher resolution and a better window management. Honestly I don't get why the resolution differs. Doesn't make sense to me. But either way I was only using DeX. If I recall correctly the reported resolution in the Browser was: 1400x876 Pixels.

• Samsung DeX is honestly pretty good and unique. You can kinda compare it to a Chromebook I'd say. You can open multiple windows and resize them and you can even make them opaque if you want to to see through. This allows you to make even more use of the constrained space. However it's not exactly the same as a Desktop. You cannot have multiple Chrome Windows open. I did find a Workaround however: If you use the Website as a PWA (Chrome: Add to Screen) you can have that Website running in its own Window.
  
  Also I want to point out that as to my knowledge, at this point of time, the iPad does have the option for multiple windows but compared to the Samsung DeX it's way more limited as you can't arbitrarily move and resize windows and minimize or maximize them so I would have been propably frustrated not having Samsung DeX.

Coding, running Servers, the Terminal etc.

Hello Gitpod

I don't even know where to start. I don't even know if there is a competitor or not and I don't even care. Gitpod is just working so so well I can't really say a single bad thing about it.

I've known Gitpod for a very long time but I barely had good use-cases for it. Since the Tablet doesn't run a proper Terminal nor can I install npm packages or even start a server or use the git command line you definitely need something like a remote environment that can do this. And hot damn, Gitpod can.

You point to the Git repository on GitHub, GitLab, whatever. Then GitPod fetches it for you in a containerized environment. The spin-up takes like a minute.

Then, on the tablet, you choose "Open in Browser" and it will run the Web Version of VSCode. You can even install Plugins, choose a Theme, etc.. It cloned my Next.js respository, I ran npm run dev in the Gitpod VSCode Terminal and it started the Next.js Server accessible for me on the Web, previewable either inside VSCode or in a new Browser Tab.

So my setup was: Add gitpod.io with "Add to Screen" as standalone Browser App and then have another Browser Window open where the Preview was.

I coded in one window and had a hot-reload preview in the other window. It felt like coding as always. Pure bliss 😍.

npm, yarn, bun, whatever you install in the remote environment will be available to you. I'm honestly not sure where the limit is but I didn't find it.

Now what I found even more amazing: You save bandwidth. Like a lot. Since npm install etc. runs on the Gitpod servers it doesn't take up any of your bandwidth. The only bandwidth it uses is your input when coding.

There is only 2 things I'd like to point out that aren't perfect:

• The gitpod config yaml file sometimes didn't behave exactly like I expected it to. But maybe I haven't properly read the documentation and also the config yaml is no actual necessity so I'm not really wanting this to devalue the overall experience.

• The App seemed to kinda perform well and try to sync when connection was bad when I was writing in the editor. But when I was writing in the terminal and connection was bad it kinda corrected back and forth which felt odd. But probably there's a reason behind it - I guess. And also this rarely happened.

How to inspect?

Short answer: You don't.

Longer answer: As opposed to some sources on the internet which claim that you apparently can activate the local inspector in Chrome even on Android I couldn't make it work. I didn't find the options and yes I do have Developer Mode activated.

So instead of just opening the inspector and checking the height of a box I kinda javascripted and alerted it - which worked but felt very inefficient. Which also means: All console.logs happening on the client are missed. The ones on the Server get logged in your Gitpod VSCode terminal.

You could however use a service like lambdatest.com or browserstack.com to open the Preview Link in a Remote Browser and then you'd be able to use the inspector there but that would rather be my last resort for bigger problems. Most often just alerting was okay.

But it's definitely not comforting, that's for sure.

Big Yikes

• I don't get why the Samsung Tablet doesn't compete with the iPad Pro in Terms of Brightness (it can't be so hard to also just provide 600nits). This would've been a Game Changer.

• I don't like the Samsung Politics of preinstalling stuff I don't want or need and not even letting me deinstall it. That's annoying as fuck.

• Samsungs UX doesn't feel as straightforward as iOS. I love the finder, it's similiar to a Spotlight search in Mac or many Linux distributions. However there is so many more options to manage/open apps that I ask myself if maybe Samsung should hire a new UX Lead. Like there is a sidebar with Apps, then there is the normal App launcher, then the Finder, the Desktop itself obviously and probably more. Someone needs to clean this mess.

• The fact that the Samsung Tablet manages heat by closing Apps is a big no-no for me. I mean my solution was to avoid direct heat (e.g. with a book in front of it) which worked well but the first time it was closing my Chrome was pain.

• No inspector 😿 (so far, happy about any good tips here!)

Big Likes

• I had to get used to the "Pro Tablet Usage" at first which took like 3 to 4 days, adapting keyboard shortcuts etc. but thats a one-off so that was definitely worth it since I'm a "Pro User" now
• The Tablet Colors and Brightness in normal environments are really convincing.
• Switching between Apps with normal CtrlKey+Tab worked like a charm
• Multi-Window in Samsung DeX was really good and helpful
• Mobility
• Battery when it's not hot (I could watch 3 hours of offline Netflix and still have more than 50%)
• Gitpod 🫶🏾

Summary

At this very moment, with a tablet, you're bound to good internet. Besides Stuff like Notion that allows you to write stuff when you're offline or downloaded Music and Videos the Tablet without internet is pretty useless IMO as compared to a Laptop where you can have all your stuff on the filesystem.

However even if many of the above kinda sounded like raging the amazement was between the lines. I was amazed, given internet connection, how far you can get with a Tablet. Especially because it has a few advantages such as screenshotting and drawing with the Pen on the screenshot directly and then pasting that e.g. into a Web Design App such as Canva. Also working in GitPod was just so convenient that I barely noticed I was working on the Web Version. The only time I did was really when the internet connection wasn't stable.

So would I recommend working on a Tablet for Coding? I'd say if you wanna have the tablet convenience and you are not necessarily planning to code for 8 hours every day but rather like 2 or 3 I can definitely say that there is not much speaking against doing so on a tablet.

Would I replace a Laptop with a Tablet? Speaking for myself I don't see this happening in the near future. I want more resolution, I want even better window management (opening new windows in Chrome instead of new Tabs) and having a fully working inspector and full access to the terminal. Still it's awesome to know that I can have a fully working, seamless VSCode without my Laptop.

If you're planning on buying a Tablet for temporarily working I'd say: Wait for one with even better battery and maybe 550+ nits.

tl;dr: This Post explains how I got interviewed by Amazon and eventually got an offer.

Why I declined

Before the question pops up let me reveal upfront: The offer was legit. However I declined the Amazon offer. Simply because I had a counter-offer at the time which was kinda identical and it didn't require me to relocate - which I didn't want to in pandemic times of embracing remote work more and more (only to notice I am going to be in Home Office in a different city).

Who the F cares?

This is for people that want to understand how interviews in bigger companies work and for people that want to understand if it is "impossible" to get in. It's not. And you got not much too lose for trying.

Take it with a grain of salt

Please be aware of the fact that I report all of this from a perspective of someone that's been long time into tech. But that doesn't mean I know all the algorithms. In fact I barely know algorithms - sure it would be easy to re-learn those but I just didn't need to by now (business-wise). I'm certainly not learning any Dijkstra Algorithm by heart for an interviewing process. If they want me to then I'm out, for sure.

The Flow

1. I got contacted by a recruiter person for Amazon when I was working for Mercedes-Benz.io so maybe that was the reason, maybe not - who knows. But at the end of the day, the overall process would've been the same if I had applied or if you are recruited - there's no difference.

2. Having talked to the recruiter I was like "Yeah sure, Amazon, why not give it a try?" (I am never hyped about a job since being hyped upfront might be the mother of disappointment. Amazon and Google are also just companies with people like you and me).

3. The process explanation:

   1. Talk to the recruiter
   2. Have a Codility Test
   3. Run through a Live-Coding Test
   4. Meet the Team ~6 hours
   5. The offer

3.1. The Recruiter Call

I don't remember every single bit of the call but the internal Recruiter was a different one than the one that initially got in touch with me. Seems like they do split the work in that regard. The Recruiter was pretty friendly and available for all questions that I had upfront. He explained that there's gonna be a Coding Test and if that succeeds they will continue. I'm honestly not sure anymore if he exactly told me WHAT kind of process will follow but I am certain he would have if I had asked.

3.2. Codility Test

Codility is a famous tool for big companies to pre-select candidates. tldr: If you fail those tests fatally there is a good chance no person will even look at it. The tasks can vary extremely in complexity and type of challenge. But these can be chosen by the company. Codility is a time-limited Challenge. This was indeed stressful for me because knowing that you have limited time and there is no one to explain to what you might be currently stuck at stressed me out. Also there is no pause button. When you start it the time runs. The timespan was 125mins. I think I finished after like 70mins but eventually left everything open to check over and over again every line of code so I stopped at around 90mins or so.

The tasks are extremely clear. There is not much room for interpretation. Of course you can google stuff but that doesn't mean that your code will get better. Take care of your code structure, make it readable and even more so code properly. E.g. if Codility says that you can assume that the input is a number then don't build something like if (isNumber). You waste your time and probably worsen your score.

Codility DOES provide a little bit of insights if you're completely wrong or not. Because there is a good amount of tests already added that you are free to run - and that really helps reassuring that you didn't code complete bullshit. But: Don't be fooled. Only because the 10 provided Tests run successfully doesn't mean that ALL TESTS will run - and you don't see all tests.

The Tasks I got weren't "out-of-universe" challenges. I felt like they were "real use-cases" which actually made the tasks fun. But still stressful.

3.3. Livecoding

Apparently my Codility challenge was very convincing so I got invited to the next step: A Coding Challenge with an actual person - Livecoding. I am not as stressed with those because meeting actual humans means that you are able to explain what you're doing. If you hate Livecoding then you will have a bad time honestly.

I am anxious as well in some situations but you simply have to get over it. There is a company that potentially wants to hire you and you have to learn to not get a blackout. It's a person in front of you, not a killer. Maybe it helps to think of Teddy Bears instead, I don't know. If you do get blackouts with all live-codings then the really only thing I can recommend is: Seek help / consult the internet for tricks to overcome it. There is a lot of lovely tips out there. Seeking help is good and no sign of weakness. Everybody has their own weaknesses.

Back to topic. The Livecoding was open for any language. The person asked me to process a few things and how I would approach certain things programmatically.

I wasn't pinpointed to JavaScript. I could have equally used Python. The online editor provided supported syntax of multiple languages. However it didn't have a "Run" button which was kinda odd for me. So you couldn't confirm if what you're doing is "correct" - but maybe that was intentionally to pinpoint you more to explanations than actual results. You have to talk and explain. Talk a lot! You can't ever talk too much. Every single step of thinking: Say it. This allows the other person to follow your steps. Don't just be quiet and say "Here that's the result".

Also I had been asked a few other questions but the recruiter prepared me upfront to read the Amazon STAR Technique (Find Info here: https://www.amazon.jobs/en-gb/landing_pages/in-person-interview). So it wasn't anything that came "unexpected" really.

Again: The Recruiter is your go-to person. See that person as your personal trainer for the processes. There is no "dumb" question - well maybe if you ask them what you should eat today, maybe that would be a "dumb" question.

3.4. Meet the Team

I was honestly right before backing off. I was told the next step would be to have several interviews in an overall timespan of 6 hours. I hate long-running interview processes. I appreciate it when companies give you options to talk but I have other stuff to do and lots of other people would've to take vacation days for that.

What did I do? I told the Recruiter. Honesty is what's important for you and the company! I said: "I don't wanna be rude but I never in my life was thrown into such a huge process and I feel like I'm backing off after the first hour if I find it intimidating or not helpful".

The Recruiter was again very nice and said "Fair points, David." and continued to explain me why they do this.

The idea behind it is to actually meet the team and have the different people in the team ask questions that might be more related to the field they are working in. Not only that but also it provides the candidate the option to get in touch with more than just the "gatekeepers of the company" (HR people).

Eventually, I found it nice because I liked the idea of meeting the team before making decisions. But it wasn't really a meet-and-greet. It was very friendly but serious at the same time (some more serious, some funnier).

In one Interview (I think there were 6 in total, one hour each) I was asked to do a little bit of Systems Design which I found a legit task for the role I was going for (Senior Frontend Engineer).

There were never more than 2 people from Amazon in each session. Mostly one asking, one ghosting (ghosting = learning how to do interviews).

The Team also asked me questions regarding the Leadership Principles of Amazon, especially in relation to my previous experience. Since I have a lot of experience I prepared those questions very well as well as I could.

The exact questions really don't matter because they are different each time anyway but they're in the format of "When was the last time you got a difficult challenge and how did you tackle it?".

But none of it like: "Where do you see yourself in 10 billion years?" - fortunately.

If you don't have a lot of work experience it might help to find relatable experiences within your life and answer with those but I would clarify with the internal recruiter upfront. The recruiter will certainly help you out with your concerns.

At the end of the 6-hour session, I was kinda exhausted. Not in a negative way but it's still a long time in which you meet different people that all have questions.

Normally that session would've been onsite. I was lucky enough for it to be online due to the Pandemic. And I also do think they should stick with keeping it online as I find it more convenient and avoid traveling (#environment).

3.5. The Offer

The Recruiter wrote me first before sending over the offer like "David when's a good time to call you?". He said something like: "The team really liked you, you made an awesome impression and I would like to explain you the offer we have for you."

The Offer was good - especially if you consider its overall compensation package. I think it was an increase of about 15% salary as compared to my job at Mercedes-Benz.io at that time. It was slightly below my requested salary but that's okay because of what I'll explain now.

The Package included a signing bonus which would definitely cover a good part of moving costs including new furniture.

Far more interesting is the fact how they help you to get started. They want to free your thoughts from "doing all of the organizational stuff"

I would get an individual that will help me find a flat - so that person will literally take care of that so you can focus on the company - which is pretty neat.

At Amazon, you will often get additional RSUs (Restricted Stock Units). Those are Stocks from the Company which are provided to you in parts over time. So a random example of RSUs is: You get 50 RSUs promised now and you will get 10 after 6 months, another 10 after 12 months, etc. And since one Stock at Amazon is worth a lot it comes down to a very awesome compensation package the longer you stay.

RSUs are also a very good benefit keeping you in the company for a longer time.

Last but not least they will help your significant other to find a new job as well - if required. So they will make sure that you can move carefree together with your family. Which I indeed really appreciated.

Summary

I hope this helps understanding potential interviewing workflows in big companies. To understand general recommendations about interviewing please also read my other post Mastering Frontend Interviews which is definitely also for non-Frontend people.

Questions?

Post all your questions here in the comments. I'd also appreciate to connect on Twitter: Find me on Twitter @activenode

Yeah, I think that's it. Hope you liked it.

I know there is carbon and ray but those didn't exactly fit my needs of a fancy theme, simplicity and readability.

So I decided to go and create a new one and here we go:

beamco.de

If you have constructive feedback and ideas for improvement please reach out to me.

One of it is the assumption that display: flex or display: grid are alternatives for floating. They are not. Period.

At this point you might think that I am crazy but let me elaborate before you agressively type comments destroying your keyboard.

display: flex is born out of a requirement that CSS hasn't solved before: Proper Layouting. In other words: Using display: block; float: ... for layouts always was a workaround. Same as in the old times when we used <table ..> for layouting.

Okay but then why should I still use float: ... ?

As I said: It was never built for "layouting" in the sense of what we understand as "layouting" today. Such that we have to get back to what it's actually supposed to do.

As the term float already states it is supposed to let things float (no shit sherlock) as opposed to display: flex which cannot let things float. So it's an awesome helper to wrap text around any kind of figure which makes up for a very awesome reading experience if used correctly.

The pragmatic explanation will be done via my CodePen where Drake will help you to understand better:

Reach out to me via Follow-Up Questions if you have any. 🔥

I am a Frontend Architect with People Management Experience (So besides the technical experience I was happy to be working together with People Management, leading peers, building up interview processes etc.)

Amazon, Mercedes-Benz.io, JvM, nodus medical and many more gave me the opportunity to work for them (meaning: I got an actual offer). Besides those few mentioned there were innumerable amounts of other interviews I was allowed to be part of - both as candidate as well as interviewer. I don't like to have tunnel vision when it comes to jobs. I do like to check opportunities from time to time because that helps me understanding the options out there as well as helps me staying in the routine of interviews.

What this post is about

This post is not about which exact weird technical challenge you should prepare for (No you don't have to learn the Quicksort implementation in 10 languages by heart other than if you are applying for a company that's name is "Quicksort in 10 languages Inc"). This is about understanding what's behind the curtains of every good interview. I won't be talking about salary in this post because salary is just something so unique that it wouldn't fit the overall context of this post.

The CV and your application letter

I appreciate your effort but honestly no one is special enough for anyone to read a book load of pages about what you've been doing and what kind of food you eat at 5am in the morning.

Most of the companies love a one page CV, one page application letter. If you say "that doesn't fit on simply one page" then you are showing your incapability of prioritisation. I know you want to show everything but the company just doesn't have the time to read the story of your life.

So if you have worked with 30 different stacks and technologies then you are very much kicking yourself out of being even invited if you list all of those next to each other. Being a FE Developer you should be highlighting your primary FE Skills. If you have worked with Cloud Technologies and Backend then that's cool but keep it short e.g. "Also I have worked with a lot of cloud and backend technologies and I love getting my hands dirty at databases".

Also don't send the exact same letter for every single position. If the role you are applying for states "You will be working on an Angular 9 Product" then it is helping you a lot if you highlight that technology first. This can obviously lead to the fact that you should mention your cloud technologies if the role specifically states that this is beneficial - if not, leave it out.

Prepare

Prepare structurally

If you get invited to an interview and the interview process is professional then the responsible person is superhappy to tell you how the interview will be structured - if you ask for it. If you don't ask for it you will literally be expecting anything.

Send them a nice mail or call them and ask "Could you tell me how the interviewing process is structured? Will there be time for questions and will there be a live challenge?" etc.

There is nothing wrong with asking how the interview will be processed and what to expect - every client can be different so every interview can have different workflows.

Prepare contentual

I remember those times of "inform yourself about what the company does". IMO this is not necessary anymore. No one will reject to hire you because you didn't know that the company has 120 employees - so forget about that stuff.

But you should still prepare and inform yourself about the company to be able to ask proper questions and hence impressing with showing your underlying motivation. This allows both of you to see if it is a fit or not. You don't necessarily have to "lie" that you "love" the products the company creates. It is sufficient if you like its process around the development part that is part of the products - on which you will work.

If you read on the roles description: "We are a high performing team" and you feel that this sounds like "we are doing a lot of over-hours" then write it down and prepare to ask if they can clarify what "high performing team" means.

But not just that. Ask what exactly you'd be doing. That is a completely valid question. As in "So I read you are working for multiple clients here, how does a typical Frontend Coders Day/Week look like in your company?".

Also ask about the culture which helps both of you identifying if this is what you are searching for / they are searching for.

But first and foremost: Don't start asking questions in the beginning like "Ok before we start I got some questions". I did that sometimes if I felt the urge of importance but I still do not recommend it as it can have an impression of being rude if you are not being very diplomatic. So rather don't and wait for the interviewer to give you space for questions.

If the interviewer does not give you space for questions it feel encouraged to say: "Thanks for this interviewing process so far. [...] May I ask some questions about the company and the job role?".

No question is a "dumb" question if stated friendly and with honest interest.

Let's talk about Interviewing

Coders be like "Oh shit, what if I can't answer this?". And then they might fall into a deep black hole if there was a question that they felt uncomfortable with and at that point I have seen many interviews failing.

The Problem is that many don't understand what the point of interviewing is. It is checking your capabilities of solving problems at the base of your current level given the expectations that you set. That means: I can ask the EXACT same questions in an interview to a senior as to a junior but I'd be expecting completely different outcomes and both could be hired respectively.

What's the trick? Act curious instead of being challenged. Try to imagine all of it less as a "test" and more like a "tell me more discussion". And not only that. Think and explain in pseudocode if you can't provide legit facts. Literally the worst thing you can say is "I don't know". A few "I don't know"'s and you are out. And not because you didn't know but because you showed that you aren't even trying to solve the problem - not even slightly.

Scenarios

Scenario 1: Sorting Algorithm Question

Interviewer: "Do you know which is the fastest Sorting Algorithm?"
You: "Sorry, no" - Awkward silence 🙅🏽‍♀️😐

This is close to ending the meeting soon. Here is a proposal of being curious instead:

You: "I don't have that at hand but I would love to know where the answer to this would help within your products scope if I may. I'd be assuming that JS engines would to their best to have a fast sorting algorithm. If that wouldn't be enough I would make sure to research properly how to improve the performance if there is a need detected." - 🤗

Scenario 2: typeof null Question

Interviewer: "Do you happen to know what typeof null is?"

Even if you know the answer to this question (it is 'object') then be rest assured that this is not a key-value test. These questions normally come with a follow up question. There is always "context" around a question.

So say you didn't know that typeof null equals object. Then the worst thing you can do is random guessing. This is not playing lotto and the interviewer doesn't like to be played. They will notice. If you have a really good guess or you slightly remember something then explain your guess and let the interviewer follow your thoughts: Think out loud! Nothing worse than awkward silence because you think you need to think silently.

If you have no clue then simply say something like: "I am pretty sure there is a good reason you asked this. Would you mind to tell me the solution and eventually have a follow-up question on this?"

Even though not knowing you are showing your willingness to go with further questions in this context after being told the solution. A very much follow-up question probably is: "Can you imagine this check being problematic?" - Now, same rules: Start to think loud. Speak up what you think - as if you were googling. Start one by one: "Okay so if typeof null is object then that implies that a nullish/falsy value can be seen as object if checked with typeof. That means that one shouldn't check for something being an object only with typeof because it could be also null." - You are literally explaining it to yourself AND to the interviewer and hence showing your skills to solve problems at hand.

Seniors, Seniors, Seniors

There is some addendum that is important for Senior Frontend Engineers. The huge difference between Juniors and Seniors is that a Senior actually should be able to answer most of the questions asked at the expert level they present themselves with. And by that I am not saying "They must know every single property / function by heart".

What does that mean?

With Juniors I mostly ask the same kind of questions. With Seniors that's different. I know you cannot keep up with every single technology but you must be extremely proficient in a specific technology and the basics (HTML, JS, CSS) so tldr: Your primary skill of the last project + Basics.

That is why I completely adapt interviews with Seniors on-demand. I do ask the Seniors beforehand about their proficiencies. If the person is being honest saying "I think I missed out one some CSS in the last 2 years but I am really good at XYZ" then I am happy to be gentle with CSS questions and focus more on XYZ (as stated above, it's hard to keep up with everything). If a senior tells me that the proficiency lies in Angular I will focus on asking Angular-specific questions. Even if it is a position as a React Developer. The reason is simple: If the Senior can deeply elaborate on my questions considering the provided proficiency on expert level then I have no doubt that this person has the capability of understanding the architecture of another framework.

And now comes the pitfall: Seniors often don't expect me to ask basic questions which is honestly shocking for me every single time. And with basic I don't mean "Which exact CSS property will let boxes to be aligned next to each other" - it is sufficient to know that display: flex exists and that you can do a lot of alignments whichever way with it. Details: Google.

But if a senior starts telling me that float: left is a good way nowadays to align boxes then it shows that that person must've ignored every single news on the internet in the last past years.

Also one of my favourite questions for seniors is to explain me the arrow function. And if a senior says "It's a function but with a different syntax" then this is a definite reason to be rejected. For good reason: The arrow function binds context - and it binds it in a way that is unchangeable. So even the functions .bind, .apply and .call cannot change that context. But they also wouldn't throw an error. So if a senior does not know that an arrow function changes context immutably then that Senior would've a hard time debugging if there was a legacy library that would be making use of older functions but now providing arrow functions leads to problems - without throwing errors.

In my experience Seniors often oversell. So if you are insecure about being Senior then rather sell as Intermediate and surprise with potential Senior knowledge than sell as Senior and surprise with disappointment. When I do ask "How would you rank your JS knowledge on a scale from 1 to 10" they often go to 8 or 9. Because they don't do much of self-reflection anymore. That backfires. And this happens in a lot of interviews. And this is something that really only happens with Seniors, rarely with Intermediates or Juniors. The problem is that seniors are often doing something very specific in a project. And more often than never they are solving the product needs with that specific solution and that might be perfectly fine and in a way that is senior'ish. The problem is that they forget that they are often "living in a technology tunnel" without learning new things and keeping up with how JS evolves. But they must make sure to keep up with the basics. And not just that. They also must ensure to not forget the basics. Because if they need to dig deeper (not every 3d-party library is perfectly working) they might need to be working outside of the scope of the framework with pure JavaScript. And that shouldn't be a huge challenge for them.

My suggestion here is simple: Stay humble and at least subscribe to 1 JavaScript Newsletter. That should already be a good start.

Rejection Handling

Rejections are hard. As always in life. And you must prepare for being rejected. Expect to be rejected. And if you get rejected then see it as just one step of a potentially large but definitely finite ladder. Because every single rejection can be seen as "a practice step for the next interview". This is hard but crucial for your mental wellbeing and for getting better.

Also don't just be mad. Answer all rejections with the question for feedback: "Thank you for having invited me. Although it wasn't a fit I would be extremely happy if you could provide me more insights and feedback that will allow me to improve". You'd be surprised how much feedback you will get - Sure, there's exceptions but the worst thing that can happen is that you don't get an answer.

Feedback gives you useful insights what exactly was wrong. Many don't ask for feedback and simply lower their self-esteem with the implication of "simply not being good enough" instead of acknowledging that it's only a step of becoming better.

A last note

Try to be yourself. Yes it can happen to "struggle" oneself into a position but that doesn't come with a bunch of happiness.

Sometimes it just isn't a fit. Everyone's different, everyone's special. Just like Friends and Relationships: Not all people bond well together. That's fine.

Phew. That was a bunch of text. I hope it helps.

Promises always chain

If then or catch return a value that is NOT a promise then it will be wrapped into a new promise and chained and forwarded to the next one. That means starting from a catch you can return a value and .then it.

All of the samples here will output Hello World1

const appendWorld = s => `${s} World`;
const appendOne = s => `${s}1`;
const log = v => console.log(v);

Promise.resolve('Hello').then(appendWorld).then(appendOne).then(log);
Promise.resolve('Hello').then(v => Promise.resolve(appendWorld(v))).then(appendOne).then(log);
Promise.reject('Hello').catch(appendWorld).then(appendOne).then(log);
Promise.resolve('Blogging').then(() => 'Hello').then(appendWorld).then(appendOne).then(log)

finally

finally cannot return a value that can be chained. Kind of implied by it's name. It is called no matter if another .then or .catch was called before. When the Promise was fulfilled in any way then .finally is called. Good for cleanup work.

E.g.

Promise.reject()
  .catch(() => console.log('Catch is called'))
  .finally((s) => console.log('finally called'))

outputs

Catch is called
finally is called

Errors inside a promise are forwarded to .catch

Promise.resolve()
  .then(() => {})
  .then(() => { throw new Error('hey') })
  .then(() => console.log('i am never called'))
  .catch(() => console.log('error'));

Multiple .catch statements are useful

Promise.resolve()
  .then(() => Promise.reject())
  .catch(() => console.log('much rejection'))
  .then(() => console.log('i can continue doing stuff'))
  .then(() => Promise.reject('another one'))
  .catch(() => console.log('catching the second chain'))

async functions are Promise Wrappers

The following code statements have the same effect:

// async
async function foobar() {
  return 'foo';
}

// non-async
function foobar() {
  return Promise.resolve('foo');
}

awaiting promises must be done carefully

If you await a promise then you need to be careful when checking for "success" because errors can be hidden.

See the following example:

const foobar = await Promise.reject(new Error('error thrown')).catch(error => error);

if (foobar) {
  // This does not imply success ⚠️👩‍🚀
} else {
 // This does not imply an error case
}

The problem is that the provided promise is properly caught. Referring back to promise-chaining now the result of the catch statement can be chained, hence new Error... is the resulting object if you'd call .then on it. And that is simply the same as calling await on it. So here foobar contains new Error... which is an object which when checking for if(foobar) returns true although an error was thrown. So you need to be aware of what your promises return.

Promise.race and Promise.any

Both race and any complete with the Promise whichever is first. But there is a big difference: race finishes with the first Promise to EITHER resolve OR reject whilst any finishes only with the first actually resolved Promise.

In this Promise.race sample the error Promise wins because it is first:

const promise1 = new Promise((resolve, reject) => setTimeout(reject, 100));
const promise2 = new Promise((resolve, reject) => setTimeout(resolve, 300));
Promise
  .race([promise1, promise2])
  .then(v => console.log('resolved', v))
  .catch(v => console.log('error', v));

In this Promise.any sample the resolved Promise wins because it is the first to actually resolve:

const promise1 = new Promise((resolve, reject) => setTimeout(reject, 100));
const promise2 = new Promise((resolve, reject) => setTimeout(resolve, 300));
Promise
  .any([promise1, promise2])
  .then(v => console.log('resolved', v))
  .catch(v => console.log('error', v));

Promise.all

This one is pretty intuitive: It either resolves when ALL promises are resolved OR it rejects when one of the promises is rejected.

// outputs ['one', 'two']
Promise.all([Promise.resolve('one'), Promise.resolve('two')])
.then((resultArray) => console.log(resultArray))

// outputs 'error'
Promise.all([Promise.resolve('one'), Promise.resolve('two'), Promise.reject()])
.then((resultArray) => console.log(resultArray))
.catch(() => console.log('error'))

You are a Frontend Developer. You start in a new company and you find code like this:

const data = await fetchData();
const a = [];

data.map( item => a.push({ t: item.subject, i: item._id })

Probably your first thought is: WTF is this 💣.

Let's make it nice:

const listOfTasks = await fetchTasks();
const idAndTitleList = listOfTasks
     .map(( { subject, _id } ) => ({ title: subject, id: _id }));

Did you feel the anger in the first sample?

You felt it! You felt it because it would've been so damn easy to make it clean and readable. Hence it doesn't matter "why it came to be there". It matters that obviously no one prevented this code to be merged (missing guidelines or what not) and that you suffer in a sense of Developer Experience.

Developer Experience to you is comparable to accessibility features to people that depend on it.

This is still a very much harmless example comparing how'd you feel if you were dependent on accessibility features because it wouldn't take much time on an atomic basis to improve the sites accessibility but you decided to not do it. And when the app/site is done it'd be a huge thing to adapt so you never do.

Accessibility is not hard

And often not a choice because:

If you do recommend to NOT implement proper accessibility in your application you are actually consulting for something that has legal impact in a lot of countries now. So that's, first and foremost, a very very good reason to inform yourself and your colleagues about accessibility even more. Source: https://www.w3.org/WAI/policies/

So if you are not developing on / in / for a lonely island then there is a good chance there is legal rules for it.

I have heard this iffy saying so often. From Frontend Engineers, from Designers but especially from Product Owners and Managers trying to intrigue the engineers to "save time":

"We can do it later"

Technically I don't see a problem in "doing it later". But let me take a metaphor for it: A fork lies on your table. You can put it in the shelf right now and your room looks amazingly clean. A rush of endorphines hits your body as it comforts with the tidyness. Easygoing. Now imagine you leave everything laying around in your room for a year. Now start cleaning the room - start even finding anything. You get the point...

"People with disabilities are not the target group anyways"

This statement never holds true. Never. Not in any single case for any application that is used by more than 1 person.

I have heard this in an automotive sector often saying "blind people cannot drive so how would a11y help?".

Ehm well a blind person can still be controlling the digital sales part of the automotive sector. Just to have a very, very clear example. I could add thousands more if you want.

Also bad accessibility always impacts pro users because it often comes with bad keyboard usage.

"Okay I'll add an aria-label and some alt attributes"

Fk no. No no no. Don't just start adding random aria-* attributes or alt/title tags if you do not know the impact. Start with the basics of understanding. Understanding is the crucial point of effortlessly using it and implementing it whilst coding. I would recommend myself but the problem is that I don't have any public sources on my own so I would need to lend you my brain.

• There is an extremely good free udacity course from Google (I really, really can recommend this): https://www.udacity.com/course/web-accessibility--ud891
• Read this: https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree
• Also you can start off at Sara Soueidan. She also has published a new course which you will find a link on her Twitter account to.
• A good read is always MDN e.g. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/heading_role

Let me prove how easy it can be to improve Accessibility

• Understand that CSS impacts a11y: If you do display: none on an element it is hidden both visually as well as in the Accessibility Tree so your <div style="display: none" aria-label="additional info only for screen readers">... is useless.
• Ensure good ratio on your designs (built-in in the chrome inspector; there is also a lot of Sketch plugins for Designers e.g.) ; https://webaim.org/resources/contrastchecker/
• Using a proper HTML structure is a very good start. HTML by definition (without adding CSS etc.) is perfectly accessible if correctly used. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML
• If you have fancy elements on your side that literally have no effect but looking cool (so content-wise not relevant) then simply hide em' semantically with aria-hidden="true"
• The alt attribute on a img tag is nothing that necessarily needs content. It needs content if the image shown is connected to the content. E.g.: You have a news article and you report about "More and more people visit the new shopping center". Now imagine there is an img tag with a photo showing a lot of people in the shopping center. Then a good alt tag would be alt="A lot of people standing in the new Shopping Center the city" . If however the image is just a random stock picture then it doesn't provide additional information and you should have alt="" (in this case the content lives for itself and the image is just a visual addendum).
• If you use modals, make sure to "Lock In". If you cannot click elements below the Modal with your mouse then you shouldn't be able to tab with your keyboard below it. But many modals do that and it's horrible for people working with screen readers because they often cannot get back to the modal once they left it. I also built one React Library to help with that: https://github.com/activenode/react-use-focus-trap

Now stop being a prick and at least inform yourself a little bit.

Providing a good semantic HTML structure, knowing how and when to properly set alt attributes (most FE Developers think they know this but in fact they don't) and the impact of using aria-* attributes can be a very good start for having basic a11y. That doesn't sound like a huge effort, does it?