My quest for laziness might be coming to a close.

First, this app project I am working on for myself needs to have all of the bells and whistles of a modern application, and by that I mean registration and login of users both custom and OAuth, a means though which a user can fill out a profile, registration validation and password reset faculties, data storage and retrieval (duh), which may or may not lead to a system of roles and permissions. Bonus points if I can figure a way to store uploads, mainly for images like user portraits, but also for images used in the content that users create. To my surprise I found that providing these things as a service is a growing area. These services offer a one-stop-shop, accessible through web and server APIs, for auth, database, and storage. I was thankful for finding these because that means I wouldn’t have to write any of this myself, but which one was the best fit for my needs and could limbo under the stick of my irritation?

Second, I started out with Google’s Firebase which I think I found simply due to the fact that Google overshadows everything so it comes up first in the search results (disclaimer: I do not use Google as my search engine, but it still came up first). Firebase’s docs is what happens when you let smart people who Know Stuff write documentation: insular, skipping a lot of fundamental knowledge, and massive assumptions that you, the person reading the docs to learn about the system, already know about the system. In short, I managed to stumble through Firebase to get it working, but I was never pleased with it. Plus, it’s Google.

Third, Supabase. They offered everything that Firebase did — including cribbing the “`base” part of the name — but aren’t Google, so they were already ahead in this race. I found their setup to be easier than Firebase. Plus, while Firebase offers an “offline” development and testing version, Supabase offers a self-hosted version, meaning I wouldn’t have to pay anything to use the platform assuming I could find a host and pay them to hold my stuff. Sadly, they have one Achilles Heel in my eyes: their back-end is Postgres, which I’m sure is a perfectly capable database, but having to deal with it through a web UI did it absolutely no favors in my eyes. I hated it.

Fourth, and hopefully last since I don’t know if there are more options out there, is Appwrite. Again, it offers email registration, OAuth pass-through for services like Google, Apple, and Discord, a NoSQL database back-end, and file storage. Like Supabase, it can be self-hosted but their first paid tier is only $15USD a month to skip the aggravation of having to find a home.

I think Appwrite is going to do it all for me. My first stop was to set up auth, and to avoid having to set up apps with third party services I started with email auth. It works as advertised without almost any curveballs, except for the fact that there’s no object-related onAuthChangedEvent like there is with the ‘Bases so I had to skimp in that department and just call Account.get() to retrieve the current user’s details whenever I need them. The second stop was to start building out the data store. I have a few domain data collections that I needed to stand up before I could start with more free-form data, and despite being NoSQL, I was able to get everything up and running without issue, setting up domain data relationships in a less-than-stellar manner but the approach is far from ornery. So at this point, I give Appwrite an A+ for ease of use, ease of documentation, and an effective project management dashboard.

But wait! Next on the implementation feature set is the built in Teams and Labels system. Neither of the ‘Bases have this, so I’m stupidly excited. Roles and permissions is one of those mandatory features that can be structured in dozens of ways depending on what the developer needs to accomplish, so I guess it makes sense that such platforms would go hands-off and let the developers craft their own. But Appwrite’s system is simple enough to not be a burden to set up and maintain, allows server API access for management, and can be used to assign and verify user permissions — something that’s going to be important to this app should I ever get it to a working state.

But wait some more! All of the auth systems offered by these services provide a bare minimum of data: email, password, whether the user was verified, and how they registered with the platform…but no berths for custom info like first and last names, user names, or social accounts, to name a few. With Firebase I sinned and overloaded the “claims” space for that info. With Supabase, I copied a trigger from their docs that stored that info in a custom table I had to make. Appwrite, however, realizes that modern apps usually need these kinds of records, and provide the means to store it out of the box. I haven’t gotten that far so I’m not sure on the particulars, but part of the impetus to use a service like these is to not have to create the most common nitty-gritty myself.

As a reward for getting this far, the one complaint I have about Appwrite is how they deal with registration verification. Behold! A poll I conducted via the Fediverse:

In order for an account registered via email/password to be verified, Appwrite first needs to log the user in. This is because Appwrite needs to know who it needs to validate. Seems legit, but in order to do this, I had to log the user in, via code, immediately after registration in order to send the validation email. Personally, I don’t like this. A newly registered user should not be logged in until they are validated; the validation email should be sent as part of the registration flow. As it stands now, I’m going to keep a banner on the screen of newly registered users telling them that they can log in, but not access the site featured until validated; when they log in unvalidated, they’ll need to check their email. It’s kludgy and non-standard — and according to the unscientific poll for science, not at all what people expect to have to do — but it’s what I will have to do, apparently.