Like the idiom says "Slow and steady wins the race". No need to burn up one's energy in the first two weeks, sometime there is a need for a break to recharge the inner batteries. That's exactly what my prolonged week-end was for.
The side benefit is that you can take a step back and look at the broader picture. I noticed there is increased activity regarding passwordless authentication. There were important announcements from apple, google and microsoft pushing this technology under the umbrella of "passkeys". In the meantime, several startups are sprouting from the ground, providing their out-of-the-box solutions. Lastly, most of the well-known identity providers are upping their game for webauthn too. Meanwhile, advertising about passwordless authentication appear on every second website I visit! Very few actually use it currently, but the race has started and is gaining momentum. Behind the scenes, I'm sure millions are poured into this.
So, where does my small one-man project fit into this? Well, surprisingly enough, I still see its usefulness due to a key difference. A small but important one. Most other solutions are focused on providing authentications "for others", with each "customer" having their own database of users. The one important thing to note here is that people will still have to register on every website, and register every device they have. Here, we take another approach. They register just once at passwordless.id, can optionally fill its profile, and every website just requires read access to it to know who is currently logged in. The user has a central place to manage its devices, for every webservice at once, has no need to re-register and re-confirm an e-mail and re-upload a portrait, etc. It has a global profile, secured by passwordless authentication. For the developers, it's really neat too. It's free, no account needed, no secret keys, no OAuth2 dance, etc. Just a http call and a redirect, that's it.
Now that this is cleared up, that the goal still makes sense and that this planned service has a purpose, we can go on!
So, in the upcoming days, weeks, I plan to focus on the API. For that part, I plan to use Cloudflare Workers
For those who are not familiar with it, it's "serverless code". You write the typescript/javascript code, you publish it, and they manage the infrastructure to call the code on demand. They do this in a pretty efficient way which runs both quickly and cost effectively.
The benefits are obvious:
- no need to maintain servers
- deployment easier
- scalable & redundant
- low latency due to its distributed nature
- attractive pricing
...but there are also downsides / constraints.
- the whole code will be loaded and interpreted on each HTTP call, so the bundle should be small
- debugging might be challenging
- the ecosystem is very young
These are really some very strong nice aspects but equally strong drawbacks. Basically, CF Workers are ideal for small tasks. On the opposite, they are really not suited for bigger projects, at least as they are now. It's not made for large APIs of big codebases/dependencies. After all, everything will be loaded and interpreted each time. There is also a constraint of a max bundle size of 1mb, which makes totally sense if you understand how it works. However, as long as the API is relatively small and focused on a very specific task, it should work just fine. However, currently, I'm facing a more practical issue that I haven't found a way to debug a "worker" properly.
Top comments (0)