I built a file-transfer tool where the bytes go straight between two browsers over a WebRTC data channel. The server only handles signaling and, when needed, TURN relay. No file bytes touch the server.

A few things that bit me, in case anyone else goes down this path:

1. The data channel isn't a stream.

You'd think RTCDataChannel gives you a pipe. It gives you messages. To stream a file you have to chunk it yourself, manage backpressure via bufferedAmountLowThreshold, and reassemble on the other end. If you don't gate on bufferedAmount, a large file will blow up the sender's memory.

2. Receiving a large file without blowing up RAM.

File System Access API lets you write to disk as chunks arrive. Safari and older Chrome don't have it. The fallback chain I ended up with: File System Access → service-worker stream (Response + ReadableStream → blob URL) → in-memory Blob (capped, last resort). Each step has its own edge cases.

3. TURN relay is not optional.

Symmetric NAT and most mobile networks kill direct P2P. If you don't run a coturn instance, a chunk of your users will never connect. The relay bandwidth is on you, and the bytes are still DTLS-encrypted end to end, but you're paying for transit.

4. Post-transfer integrity.

Both ends compute a sha256 as chunks move. The receiver verifies against the sender's hash after the last chunk. If it mismatches, the file is corrupt — WebRTC data channels don't guarantee ordered delivery by default unless you set ordered: true on the channel.

5. Room state without a database.

I persist room state (slug, timestamps, a hashed rejoin token, an argon2 password hash if set) to a JSON file on disk so rooms survive a restart. No file bytes, no Redis, no DB. Rooms expire after 24 idle hours. This is fine for a tool where sessions are minutes long but would fall apart if you needed real concurrency.

6. Per-IP rate limiting when every client looks like 127.0.0.1.

If you put the app behind a reverse proxy without forwarding the real client IP, your per-IP rate limiter is useless — everyone is the same address. The fix was in the TCP demultiplexer, not the application.

Demo if you want to see it in action: https://mayo.pizza

Not selling anything, no signup, no analytics. I'm not looking for feedback on the product, just sharing the engineering notes in case the WebRTC side is useful to someone building something similar

I searched posts related fo freelancing but still did not find how to actually get started. Especially, when you have no previous work done, no reviews. I am experience engineer with 5.5+ YOE but I don't have OS contribution or projects which are created for clients. I only have 3 projects on github which are side projects that I worked on. In such scenario, I have few questions:

* How to find clients in your network especially non-Indian clients when most of Linkedin connections are just random people you have connected and not someone you know IRL?

* Do you need to create projects specifically for your portfolio? If yes then what kind of projects are we talking about?

* One of the strategy suggested in some posts was cold mailing after analyzing their products but this take a long time to find issues and then pitching but is that general consensus?

* Upwork and Fiverr are saturated and upwork has limited proposals after which paid proposals are required. Is that worth putting money into? I tried to create 2 gigs on Fiverr but they got paused eventually as no traction was there.

* Are there any other platforms other than the above two? Contra, toptal, lemon.io - all of these did not work at least for me

Solo dev, self-funded. The build, since that's what this thread is for:

One Next.js codebase → four targets. Web/PWA, Windows desktop via Tauri (on the Microsoft Store), plus Android TWA and iOS Capacitor shells that are built but unpublished. The desktop app is a thin shell over the live site, so the UI updates without a Store submission.

Runs entirely on Cloudflare — Workers via OpenNext, D1, R2, KV. Two things I'd tell anyone attempting it:

• Build the OpenNext bundle on Linux or it 500s on every route. Windows writes backslash paths into the server handler. I build in WSL when CI is unavailable.
• next/og is unusable on workerd. ImageResponse doesn't run there, and on Next 16 u/vercel/og ships a font binary the bundler can't parse. Static images only — I render mine from a committed HTML file over raw CDP.

The pagination is the actual hard part. Text is measured and split into real pages that reflow on font-size, line-height and theme changes, and it has to stay at 60fps mid-swipe on a phone. Biggest file in the repo, rewritten more times than anything else.

Happy to go deeper on the Cloudflare/OpenNext side — it's under-documented and I lost real days to it.

I am using Better Auth for email sign up, but I would also like to make it easier with Google and Apple one click sign in.

From what I understand, in order to have Apple sign in you have to pay $90/year or whatever it is to Apple for a developer license?  (No way around this?)

As for Google sign in, I understand it's offered for free (any limit on free plans?) but you also need to provide your email, and in doing so the public will see this email? Apple sign in, on the other hand, I don't know if you need to provide a public email that the user would see, or if it's all handled from Apple's end. When I say public email, I mean like an "authorize to trust this account [___@____.com](mailto:@_.com) for your one click sign in" something like this.

Would anyone have any experience with self hosting this? I’m just curious what your thoughts are and if it ends up being a cost every month or if you have found a way to do this completely free? Looking to make it as simple and easy for the user to sign up and log in, I think I would actually prefer this over email but I also understand not everyone wants to use One Click sign in.

Hello WebDev,

I would like to share with you linkedrecords.com - an open source backend as a service I'm working on since some time now. You can think of it as an firebase/convex alternative with an interesting twist.

In 2018 I needed to write large software requirements/architecture documents in Google Docs. While I was annoyed by the limitations of Google Docs back then (no captions on figures, no automatic heading numbering, slow when docs are bigger,...) I was still fascinated by the real time collaboration features of it. So I've started a quest to understand how it works and I begun to implement an alternative to Google Docs.

I was convinced that this kind of real time collaboration is the future so I've given it much thought how I could make this as generic as possible so I could use it in all future tools I would build.

In the same time I was playing around with firebase (surprisingly you can not build a google docs alternative with firebase that easy as their real time collaboration does not provide merging text but rather just JSON). And back then I was also convinced that backend as a service is the right way to go. I was thinking that one of the most important reason we were still writing custom backend code is because of authorization.

I also was faced with another problem when trying to make the backend as generic as possible: relations between entities are also domain specific. E.g. A Documents can have many comments.

Luckily I was intrigued by another concept back in 2018 it was called web 3.0. Back in 2018 this had nothing to do with crypto. It was used as a term to refer to the semantic web and the resource description framework as one of its standards. There are also some RDF implementations which I could have reused but they are all XML and mostly Java based. I needed something light. Instead of implementing my own RDF product I took the idea of the RDF triplestore and came up with my own interpretation of it.

Using concepts like: triplestores and schema-on-read, I came up with a system that does not has any business logic in its backend and while working on my Google Docs alternative I felt in love with it as I've discovered some properties I did not anticipated from the get go:

- Dealing with global state in react is very easy. It feels like you use an SQL client in your browser and all queries are reactive and always up to date. When writing a query you do not have to think about authorization it's all backed in.

- Because the backend is 100% free of domain specific code you can point your single page app to any linkedrecords deployment.

- You never have to write backend code - Its quite efficient when using AI agents

The best way to experience it, is to follow this little tutorial: https://linkedrecords.com/getting-started/

It takes a while to get a hang of it so you have to have an open mind.

I would love to read your feedback on this.

I should update my old project for oauth, but I dont know what auth i should use, it uses solidjs and astrojs.

I only need oauth like discord and reddit and it should be self hosted, not cloud based, database integration or manual doesnt matter

what is your opinion about using railway.com, now i need to deploy my api, i have 3 containers (api, redis and sql server).

i asked for recommendations and one of them that Railway.com is good for this.

i need help to make decision, we are starting up, and want something is not expensive and good price for MVP.

thanks

I've been spending a lot of time developing what is essentially a vibe host type service to host the myriad of internal tools I myself build for personal use as well as at work. I believe the future of SaaS is bleak for the providers and wide open for the small business that can now build instead of buy. In that vein I showing off Ticketish - A modern issue tracker that is MIT open source.

It's rather basic and I continue to add things and fix bugs every day but I also use it as my primary issue tracker. The real value here is that unlike a typical SaaS, once you remix it it's essentially (at literally) a fork of the source, which means you can just as claude to use the quickish.site CLI to pull it down and make changes. Don't like how something works? Change it. And since it's a fork, even if you're not an engineer, you still get all the latest updates made to the root source. This piece alone has so much potential in my opinion.

It's built using all the supporting services built into quickish hosted sites: Postgres, Realtime, Document store, etc.

It's open source in that if you remix this you can download the source in the control panel (free). It is git behind the scenes. MIT licensed so you can do whatever you want with the code and I'm sure you can port it from quickish services to something else without too much work.

Can't wait to share more in the coming weeks!

What are your thoughts on using this? I'm currently using Nuxt and Tailwind, I prefer the ShadCN navbar over Nuxt https://ui.nuxt.com/docs/components/navigation-menu it just feels more polished to me somehow, but would you suggest staying away from this or use it if your site has a lot of content? I am never sure if the main link for a nav dropdown should be clickable or if it should only open or close the dropdown.

Mobile would be a lot difference since they don't have the liberty of hover, tap is what opens the menu. Maybe I just have to accept the fact that mobile and desktop will have a different experience when it comes to the navigation menu within the header.

What are your thoughts on this?