refactor: create a new search frontend using SvelteKit #203
Conversation
missing some correct design details: - fonts - gradients - colors - roundedness - icons no functionality yet header links broken on mobile
|
Hi there, Realmy here. Personally I prefer using a chat application rather than a thread because it's more fast paced. I don't mind using Matrix, but I prefer to use Discord if that's not a problem. |
|
Cheers @RealmyTheMan! You can find my discord @ on my GitHub profile and send a DM, if you're better reachable there. I'm available both in the Mwmbl Matrix and on Discord. |
|
Re hosting, we can host on our existing server. It's easy enough to create new dokku app and subdomain pointing at it (we do this for beta.mwmbl.org) - let me know if this would be good. For deploying, we can implement CD so that we deploy on merging to a branch - I've been meaning to do that for a while. Re communicating, if you're using Discord, please can you create a new room and add me so I can be in the loop, thanks. |
Yeah, that would be great! Dokku requires a Dockerfile, right? I could make one too, I'm pretty knowledgeable. |
|
Yup that would be great. Check out the existing one if you want to adapt it. Static files are served by nginx |
|
Docker file made. The static files are built in to the application automatically. Is it vital that they be served by Nginx? It shouldn't add much server load if it's just favicons and opensearch and such. |
|
Not vital but I'm not sure what the benefit would be? |
|
Benefit of what? I was just responding to:
The only benefit to not doing that is that it's just easier; node serves them just fine by default. |
|
Ah yes, that explains it, so do we need node? because we already have Django and I'd rather avoid the complexity of multiple servers. |
|
SvelteKit uses SSR by default, which obviously requires Node. It can be changed to SSG mode, but then some features are lost. I had planned to use a SvelteKit server endpoint for relaying the auth, since that would enable storing a JWT refresh token in a HttpOnly cookie, making the auth slightly better secured from XSS. Otherwise we wouldn't be using any features that require Node, so we could just switch to SSG mode and just forget securing cookies with HttpOnly. An additional benefit of SSR is that dynamically rendered elements, such as search results, would not require JS to render initially. This would make the site more accessible to clients that disable JS or otherwise have limited computing power. If Nginx or another reverse proxy is already used (as should IMO), I see no problem with running a separate NodeJS server for the frontend, considering the benefits and just letting the reverse proxy handle requests to that. Isn't it pretty normal for an API and a frontend to be hosted in different processes? If computing power is a concern, but Cloudflare is not, it's also still possible to host the entire SSR frontend there for free with no bandwidth costs. |
|
Yup if we get it to work without JS then it's worth it. That's one thing that a lot of people complained about with the original spa. Let's keep it as you have it. We can use api.mwmbl.org for the API as we did originally |
|
In which case, let's use a separate repo. I was thinking we could do some weird mix of Django and svelte but with another server I don't think that will work |
|
You can create another repo and add me as a maintainer. I'm not sure how to transfer the commit history from here, but git might have something figured out for it. Edit: I found https://gist.github.com/trongthanh/2779392 |
|
Re search as you type, let's leave it for now and consider adding it again at a later stage |
|
Again re bundling results, not sure fussed and definitely not needed for a first iteration. Curation etc is more important. |
|
Moved to the new repository successfully: https://github.com/mwmbl/front-end I'm going to close this PR now, and move the main content to an initial issue in the new repo. |
As per discussions on the Matrix, here's a PR for tracking development of a new SvelteKit-based frontend for Mwmbl search (and eventually other features).
Also see, development README: https://github.com/xynydev/mwmbl/blob/main/sveltekit-frontend/README.md
Screenshots
(from commit 5fbde32)
(use the "edited" dropdown at the top of the post to see progress)
Front page
SERP
Design
The current design is loosely based on this image posted on the Matrix by Daoud showcasing a design draft by
@realmythemanon the Matrix channel (who does not appear to be using Matrix anymore). It's still missing most of the basic correct design details: fonts, colors, gradients, correct icons and rounding constants.I'm hoping to get in touch with
@realmythemaneither in this thread or on Discord if that's not possible, to figure out the design details and collaborate on the design.Technical decisions
Framework and programming language
I opted for using SvelteKit (with Svelte 5 (runes) preview, though that may be reconsidered if issues arise) and TypeScript, because it is a combination I find very pleasing to work with, while enforcing a structured codebase and supporting filesystem routing. Svelte is especially nice since it works through kind of a compiler, making the client bundle smaller and more efficient. The new rune system with Svelte 5 implements a signal-based reactivity system very similar to other popular frameworks, which should make it pretty easy to adopt for developers new to Svelte.
CSS and UI
I opted for using TailwindCSS for styling, since it makes it easy to develop style and layout alongside the semantic HTML structure, without having to come up with classnames or context-switch to CSS. Additionally, it works as it's own standard and has nice defaults, making it possible to read HTML and understand how it looks, without having to learn what a bunch of custom classnames look like.
I like to pair Tailwind with shadcn-svelte, which is a "component library", a set of accessible and well-styled (with Tailwind) prebuilt components that are inserted directly into the codebase where they are used.
shadcn-svelteis great because you always get something functional and accessible that follows best practices, while getting free rein to customize components as you see fit.Misc
npmand some of the command line syntax is nicer. Usingpnpmis totally optional, though, and the project works with or without.Where to host?
SvelteKit can be trivially hosted on any platform for which an adapter exists. I've personally enjoyed "serverless" PaaS hosting on Cloudflare Pages, which does not charge for bandwidth, which should be enough to prevent Mwmbl from getting a $104K hosting bill.
Hosting on bare metal (or VPS) is also possible with the NodeJS adapter, if hosting the frontend in the same place as the backend would be preferred.
TODO
/search, whereas with the old frontend it's in the root path. If someone queries/with the?q=queryparam, they get transparently redirected to/search?q=.opensearch.xmlbased on the pre-existing one with small edits, but I was unable to see it working in development.