Supaboost V1.6 - Authentication, SSR and useHooks
The new Supaboost version is here. On the 10th of February, we launched Supaboost V1.6, that is action packed with new features to make your life as a developer much, much easier. Some of these changes are updates, some are new packages and most are aimed at improving performance, reducing number of queries and improving readability of the code. So much, that even Lee will get it!
Let's have a quick glance at all the changes we have applied to Supaboost in version 1.6.0
- Moved from the supabase/auth-helpers package to supabase/srr package
- Implemented useHooks
- Updated Authentication and flows
- Improved readability of code
With launch week X of Supabase, Supabase introduced a replacement for the auth-helpers package: @supabase/ssr package. This package consists of fewer helpers, which makes it easier to use. Right now, we only have Server and Client component, which makes important that much easier.
Supaboost has implemented the ssr package completely throughout the application, rendering the deprecated auth-helpers package useless.
We implemented in such a way, that you can simply import the ServerClient or the BrowserClient (Client component) from the Library. This significantly reduces the number of lines your project.
On top of the ServerClient and the BrowserClient, we added an additional library that reads the users' session. This can be imported throughout your application.
All in all, we can say that Supabase has done a tremendous job with the new '@supabase/ssr' package, and we hope they keep improving it.
While Next.js and other React frameworks are aiming to move completely towards Server Side rendering, there is still functionality in the Client that we would love to use, such as useContext and useHooks.
After figuring out a proper way to implement this, we can say that we have succesfully implemented useHooks for all the content within Supaboost.
So why should you care about useHooks?
- It reduces the number of fetches required from Supabase -- If your app grows, you will be extremely happy you have implemented it this way
- It improves performance -- With fewer queries and fetches its possible to improve the performance even further
- You don't expose your url and anon_key to the network -- When you use client components for your fetches, you will expose this information to the console. That way any application logic can be bypassed by your users, using the Supabase API.
- Reduces the number of lines of code in your pages
The problem with useHooks in SSR, was that we were unable to use the state import from React (useState). This means that the conventional way, or rather, the way we were thought was not useable anymore. That is, unless you want to run everything in the Client.
With Supabase, we are able to fetch the data and rename it directly to some other object name. This means we don't have to update any state. As such, we can export the data in the hook and fetch it from our pages or components.
Within a single useHook, we can add multiple queries. In Supaboost we implemented a useHook per table. That way we can export data only related to a specific table within the same hook. If you need data from multiple tables, you simple add each hook that you require.
On top of the useHooks, we also implemented a Library for reading a users' session. Each page imports this session, to make sure your pages are protected. Within our hooks, we can use this data to make sure we only query data related to this specific user.
It goes without saying, that we also implement Row Level Security. But in Supaboost, you can also query the information of your team members. Sometimes you need to implement a smaller scope.
While Supaboost already had a proper way of authentication, we took a look at how we could improve it.
One of the important topics, was that we needed to update how to authenticate, as we moved to the new @supabase/srr package.
What has been updated:
- Email/password flow based on SSR package
- Implemented OAuth providers (Google, Github)
- Added forgot password flow
- Laid the foundation for more social authentication providers
As the initial authentication flow was build using Client Components, we had to update the authentication flow to incorporate Server-Side Rendering (SSR). The Next.js 14 (and 13) logic made it harder to use the Client component for authentication.
This also means that during the authentication, both sign in and sign up, there is no more information displayed in the console about log in data (supabase url and anon key).
To display the functionality, we have implemented OAuth including Google and GitHub authentication. With the implementation we also decided to update the UI slightly.
The original authentication used username/email and password. Adding more methods to authenticate, also means that there are more Buttons and such in the Login page.
The documentation will be updated to make sure you can find information about updating the current authentication methods. The implementation makes it much easier to implement additional authentication methods, such as Facebook,
Another important update is implementing forgot password. With the supabase.auth functions, we are able to request a reset email, lead the users towards the correct url, then give them the possibility to reset their existing password.
This reduces the required support, especially as you gain more and more users.
While maintainability is vital for Supaboost, we also aim to make the code as easy as possible to understand. With that said here is what we aimed to achieve:
- Reduce number of lines in pages
- Create seperation of concerns
- Move Supabase imports to library
- Move Queries to Hooks
The below image is an example of one of the pages. Here you can see all four points mentioned above implemented. The code is much cleaner and easier to understand than before.