https://supertokens.com/ logo
Join Discord
Powered by
SvelteKit Integration
# off-topic
d
Anyone got experience with Svelte / SvelteKit?
i
I have general experience with both. I started working with SvelteKit for a side project before I rewrote to Remix. Have you looked at the SvelteKit SuperTokens example repo, or are you trying to use the prebuilt UI?
I don't think it's worth trying to integrate ST with raw Svelte because there's no standard/"consistent" routing solution for Svelte besides SvelteKit.
d
Yep, doing pre-built UI (the new one)
It wasn't hard or anything... routing threw me off a bit
I didn't find an intuitive way to do catch-all routing (had the same issue with Astro)
And yeah, I gave up on doing a regular Svelte integration exactly because of the lack of standard routing 🙂
I'm not against DIY-ing stuff, but I don't think I have it in me to write another router 🤣
i
Yeah I hear you. Mkay. Not sure I can help a whole lot here then. 😔 because you guys do a fall-through to get the prebuilt UI working with these things, right?
d
seems to works - possibly not the cleanest approach
and yes, I'm kinda brute-forcing a catch-all route in the router folder... 😄
but I'm kind of an absolute n00b with Svelte, so I may have missed something in the docs 🤷‍♂️
i
Powerful. I'll probably have to try it out on a different day. But if you were able to test it manually hopefully it works fine.
I know I've asked this before, but I am still a bit curious. 😅 When I see the examples in 
create-supertokens-app
, it seems like whichever SSR framework is used has to be wrangled to work with the Pre-built UI. Is it worth the effort? I see a lot of helper functions being created in the example projects. So I'm assuming that roughly the same boilerplate (if not less -- unverified 😅) would be needed to re-create the Prebuilt-UIs manually. Is that accurate or a poor assessment?
--- I'm mainly thinking about how easy it will be for consumers to customize the experience according to their needs in situations like these. If someone wants to customize the server logic, will the path be obvious? I know one person in #1224328457589227540 was running into a problem when they wanted to use Server Components and no Client Components (because the example project's code was intermingled with the Pre-built UI).
d
great questions 🙂
the prebuiltUI is a get-you-started-quickly thing
as things are, we do those in React; The new prebuiltUI is basically a compiled version of all that, which makes it kinda universal
now personally, I prefer going the custom UI route; But a big chunk of our users prefer the prebuilt stuff
I'm not sure what the difference in boilerplate would be, tbh
i
Yeah getting started quickly is huge. I would think that could be accomplished in a few ways, though -- at least if you have an SSR framework. > But a big chunk of our users prefer the prebuilt stuff This one I'm curious about. Did you guys do a survey sometime ago (or recently) to verify? If so, I'd be curious to know if the pre-built UI popularity could be related to: 1) Is the audience largely working with some SPAs of some kind? 2) Are the docs/examples for creating a Custom UI less clear/quick/easy? 3) Is the audience largely using the framework integrations (e.g., Express)?
d
I don't have the numbers, but from what I've gathered so far
The earlier the company, the higher the chance the use prebuilt (time constratins and shipping)
The bigger the company, the bigger the tendency to go custom
i
Yeah that sounds about right 🤔
d
there's the weird outlier (yours truly among those numbers), who prefer custom in general 😄
I prefer functions to components when integrating any kind of a service
but I totally see the benefits of going prebuilt
i
But that's the thing. If you can copy-paste/download boilerplate from someone else, isn't that more or less the same as a prebuilt UI? You basically get the same "download and forget" benefits, but you have more control to modify things if needed. SuperTokens doesn't currently have a lot of examples for that, right? So I feel like at the same time, it would be hard for people not to prefer pre-built if they have to do all the exploring/setup on their own.
I'd be interested to see what the preferences would look like if there were more clear docs/example repos for custom servers/frontends. Because if someone can't 
create-supertokens-app
to get a clear custom version (or if the app generator only uses pre-built UI), the devs are kind of getting funneled in a specific direction already. Only the stubborn people (like us 😅) would escape.
d
Those are fairly good points, @ITEnthusiasm 🤔
i
Yeah. I think they're worth considering. Question: Is 
create-supertokens-app
intended for 
npx *
only? Or is it also intended to be a frame of reference to help developers understand how to integrate X Framework with SuperTokens? The reason I ask is that I find the stars on 
svelte-kit-supertokens
(14) and 
remix-supertokens
(24) to be larger than those on 
create-supertokens-app
(13), despite the fact that the lattermost is officially maintained by the team and has been linked to in various places. That isn't intended to be a flex. But I do wonder if it's any indicator of what developers want/need with respect to SuperTokens. (There could be other factors that play a part here that I'm unaware of too.)
(Not trying to start fires. I'm genuinely trying to look out for SuperTokens' best interest -- with my limited knowledge.)
d
no worries, that's fair 🙂
create-supertokens-app
, the way I see it, is primarily a learning tool (not a scaffold); It can be used as a scaffold, if you want one. However, I don't think people commonly start projects with auth as a first consideration.
so, the goal with the CLI is to help people understand how they can integrate SuperTokens in their projects
doing custom UI for the CLI would be a ton more work, IMO (not that it's not worth doing, however; it's just not a small amount of work)
i
Okay that's helpful. So it sounds like it is intended to be a tool largely for learning then. In that case, from the stars, I would consider the Custom UI route worthwhile since it would help people learn how to work with SuperTokens and 
<Framework>
as they need. Can I ask what would make the custom UI significantly more work? (Again, sorry if you're rehashing things you've already said before. 😅 I feel some déjà vu here.) I assumed the CLI was basically just 
cp ...
from the 
boilerplate
folder. Is that incorrect?
d
You can, should and thank you for asking 😄
well, it would be a lot harder to generalize the set of functions, config we need and shoehorn them in a CLI which would work with all of the different framework (and metaframework) specificities out there
e.g.
the configs would probably remain mostly the same, but the way we handle router calls, intercepting requests etc. would vary from framework to framework
I'm not even doing the explanation any justice if I'm honest, but just thinking about supporting custom UI in the CLI for all of the options we currently do, makes my head spin 😅
but you're also right in that we should make some examples or scaffolds for custom UI
I already have a few up, in fact
problem with those is, they usually cover just a single auth recipe - so it's email/pass + social
and sure, that's common enough, but it doesn't cover every use case out there
i
A lot of the reputable frameworks gaining traction right now just use the native `Request`/`Response` objects. In my experience, as long as the helper functions used don't try to know too much, you can get a lot of reusability between frameworks. That's at least what I've found for Remix and SvelteKit. I expect SolidStart and Next.js app dir to be the same. (Next.js is a little more tricky since middleware still isn't in the Node.js environment yet. But you still get to reuse a lot for the most part, it seems.) Most of the discrepancies/differences have been just the layout of the filesystem because a lot of these frameworks have filesystem routing. (I wasn't sure what "intercepting requests" referred to. But I assumed it was related to having some kind of "middleware" that checks whether or not a request is authenticated.)
Are you thinking about multi-tenancy? I'd be curious to know how common the other various use cases are. I'm sure their important and definitely have their uses. But even if the examples that SuperTokens provides aren't comprehensive, they could give someone a starting point if the code is clear enough and SuperTokens' functions are generally flexible enough.
d
That's an interesting point. And I'd agree with most on that list except Next - they tend to do some interesting things over standards 😅
Routing is another issue, yes
For example, I couldn't figure out how do to a catch-all route that can catch child routes too in SvelteKit and Astro. In most other frameworks, that's trivial.
And yes, I meant auth state checks by intercepting, should have explained that one better
Yes, in part at least - also stuff like MFA, etc. Basically, anything that can change the normal flow or might require extra screens (on extra routes) to be rendered.
But whenever I write integrations, mine is not to question how often it's used 🙂
Sure, some of those options are used less often - that doesn't make them unimportant to make an example for 🙂
at least, IMO 😄
i
> And I'd agree with most on that list except Next Yeah I would agree that Next.js is pretty weird. Not the best ergonomically. 😅 But even with them, I've been able to come up with a solution that allows me to re-use most of my code without bucking against the framework or losing reusability. In Next.js, most of the deviations come from server components. 😕 But that's more markup-related. I was able to do a quick test that worked, but I've put that implementation on pause because I really want to finish Passwordless on the Remix/SvelteKit examples and I'm almost done.
> For example, I couldn't figure out how do to a catch-all route that can catch child routes too in SvelteKit and Astro. Yeah that bites. I guess what I also have in mind when it comes to these things is "Custom UI + Framework-driven Backend". From that perspective, you can usually replace catch-all routes with the framework's Middleware concept (SvelteKit's server 
hook
) or a server-only function that's used on all guarded pages (Next.js). That's where I've been able to maintain reusability. I could understand how trying to do catch-all approach consistently could be difficult though.
Yeah I agree that if a feature is important for another user, we shouldn't tell them isn't unimportant. 👍🏿 I was mainly thinking about what's "most profitable" for SuperTokens. It's a design optimization problem of how many examples the SuperTokens team can actively maintain given their demands and resources, as well as how helpful the examples will be for the community and how many more developers they attract.
d
ah right, middlewares and hooks - when they work it's great, when they don't... Let's just say my desk has a small dent now 😅
Case in point, Astro (but SvelteKit wasn't far)
in Astro middleware, you can pretty much define a router
but, it behaves weirdly
it catches a request for auth/*... logs that it got a request ... passes it on ST, which validates the session... and then goes on to throw a 404 as a reponse to the client side 🤦‍♂️
ultimately I decided that all that frustration isn't worth it
and just added some copies of the same file for handling auht requests at all the relevant levels
and more importantly, I love Astro to pieces and I still think it's the best thing on the web since organically grown HTML - but it has downsides, like the one above
i
That's very interesting. I would expect Astro to do better. 🤔 I'll accept that as a challenge to try out their middleware myself (and likely fall on my face 😅). Hopefully I can get Passwordless (and Next) done soon to see what it's like. But that does sound like a bother.
d
well, the middleware was never meant for that particular use case, from what I gathered
i
(sorry to interrupt. keep going)
d
they are addressing that issue differently tho
adapters, as it turns out
instead of using a node adapter (the default one for SSR)
you can use something like Express or Fastify
which gives you access to full-on programmatic routing inside of Astro
the ordering is
Request -> Express or Fastify -> Astro -> Response
if Express or Fastify don't have a route defined to handle the request, they simply pass it on to Astro
which makes a ton of sense for catch-all scenarios, for example
i
I see I see. That is interesting.
Yeah in Remix I had to lean into Express as well, though it wasn't too inconvenient.
d
yeah, I mean we might be trying to shoehorn too many things onto metaframeworks 🙂
sure, there's an SSR component there
but they were never meant to be used as APIs
or that's added as an afterthought
and it often shows
i
Well I can't speak for Astro, but it's seemed to me that to some extent frameworks like SvelteKit and SolidStart have intentionally tried to make room for making API routes easy. Remix also has that; but for "global middleware" I think they got lazy because they knew they could defer to Express. (You can still accomplish what you need in "Remix-land" by using higher-order functions that serve as auth guards, though.)
d
yes, true, but here's a question - given an API-only project, would you choose a metaframework or something like Express?
i
lol that's fair. I would probably reach for Express (or something else that made working with requests/responses nicer). At the same time, if I wanted a web app that had authentication, I'd probably reach for a metaframework. For me it's a question of whether any UI is needed.
Lowkey I'd like to try HTMX at somepoint. But I'd probably try Go for that over Node + Express. 🤔
d
HTMX is refreshing 😄
I gave it a spin, it's truly different
and if you wanna try something truly different, give this a spin https://ahastack.dev 😄
it's really contrarian, but not necessarily bad 😄
i
Very intriguing. Yeah I'll have to check this out sometime.
On this note, if you have any other features in mind that would be more common but potentially more effort to implement, I'd love to know them. I want the Remix/SvelteKit/X integration examples to be as complete as possible so that people can have the most flexible backends/frontends while minimizing headaches and client-side JS. (Of course, I can only do that as I have free time.)
Password Reset required some extra screens but wasn't too much effort to implement server side. Hopefully other pages will be similar. (Passwordless has been that way, at least.)
d
👌
btw, I'm game for pitching in, if you're open to that 🙂
i
Absolutely!
Mainly coming back here to archive some things. I think [this comment](https://discord.com/channels/603466164219281420/1294311977228701807/1295772655462645831) (along with the GH stars) is another indicator that users might like/prefer a different approach (and even consider it easier), but they may not be aware that such an approach even exists. So they end up just working with what they know based on the docs. I know time is on the lower end and that this isn't necessarily able to be addressed at the moment. But if user satisfaction is of interest as the discussion evolves, I figure it's worth drawing attenion to. After ironing some things out, 
ThirdParty
should be done soon. Then I can look at Next.js. Eager to see where code sharing will be possible. I think there's still a lot of potential there.
d
Good work @ITEnthusiasm ! I'll have a look at it soon 🙂
4 Views
PreviousNext
Powered by