How are people able to just spin up Google login using these libs? When I tried it doing it directly my site had to be reviewed multiple times by some Google rep and I had to change the privacy policy, not have any beta features etc etc. What am I missing? I find it really strange that I must fully launch my product before I can enable the most common login mechanic. It feels like a catch 22.
Looks interesting. I like that you can plug your own identity provider quiet easily. One nit: They should really rename their Node integration to Express integration because that’s what it is looking from examples (and that’s what people might commonly look for).
Does anyone have experience with https://lucia-auth.com ? OP says that it's deprecated, but it seems like it just changed from a library to a short guide on how to implement auth yourself.
I'm planning to migrate our authentication and session management from auth0 to this to save costs and make things simpler.
I am currently self hosting former gotrue, now supabase auth and am having a hard time implementing oath and will probably try to switch to better auth. The docs look super comprehensive.
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but this new wave of of SSR-led full-stack frameworks is tricky.
I've worked on a wide range of projects that use a number of different approaches to this. At the end of the day, you usually want at least some parts of it to some extent. If you don't want every page the user sees to be full of loading spinners at first, whatever is serving the initial HTML needs to know at least something about what the UI components are like and how to lay them out. In fact, the closer the initial load to the final result, the better. On the other hand, you also want interactivity, especially in this day and age. Very few web applications are just static data you look at and don't interact with. So you also need some frontend stuff that adds all of that magic. So all these frameworks are essentially trying to solve this problem, how do you get both of those things without just duplicating and syncing all of that code between the frontend and the backend. I do agree that many of the solutions we see today are immature, but when it's done right, it's wonderful.
I am a big fan of Gleam language's Lustre[0], and due to its functional nature, the full stack experience is much better.
Instead of becoming this mishmash of backend and frontend, there's a clear delineation between the two. They share common functionality via functions (like model and views), which is much easier to do when they're pure.
You basically get the advantages of those magic frameworks without all the magic.
100% agree with how confusing it all feels. Smudging data and code back together feels like a massive step backwards. I can't but be reminded of the disaster that was ASP.NET Webforms.
It took me a while to grok that in SSR frameworks, you shouldn't treat the SSR backend as a data backend. The best mental model is that the "SPA" just now has a client-server boundary in the middle of it. You should have a normal data API servicing the SSR backend.
With this approach, this does mean that client-server auth can now either live in the SSR backend or as normal on the data api. Arguably doing it on the SSR backend makes the most sense since that is now your server boundary. In this context the resurgence of auth in the SSR space make sense.
In my, arguably limited experience compared to some other folks, completely agree. It feels lite the correct solution here is to treat it as another kind of backend. I always keep the truth-keeper backend separate and with much higher quality requirements.
I started a side-project in SvelteKit a while ago, and so far I still like it a lot. When I saw what projects using it look like, it somehow just intuitively 'made sense' to me. For me it's also just the right amount of 'magic' so that it's still quite flexible, but takes care of the parts that would be tedious otherwise.
(I've never worked with Nuxt or Next though, so I can't directly compare them.)
I don’t think the issue lies in using the same language to write the client & server. IME projects become brittle & hard to refactor when you use a full stack framework because you wind up writing a ton of controller code or a sprawling service layer to support different features for each page. This isn’t exclusive to using a framework, I’ve done the same thing with API endpoints in the past.
Making a general purpose API as if it were its own product seems to lead to better, more sustainable outcomes.
In my opinion the only real point of those frameworks is so that developers can focus on coding while the experts figure out how to do code splitting, search engine optimization and what to render where (browser, server) and when.
Since http protocols and browsers change and especially google never ceases to push new optimizations, it is extremely difficult to keep up and do the right thing.
Took me 30seconds to conclude this has a 99% probability of being crap, the styling. Flashy letters means once you go to the substance you will find it severely lacking.
reply