Web Development

Is there any good courses that cover the more technical aspects of backend development? Here are some examples, not even limited to this, but I want to hear more than the basics and also some security things to look out for in like a yt video or something, potentially includes, CORS, Cookies, JWT, server side sessions, server side rendering, websockets, server side events, html patterns (e.g the backend returning html components to be place into the browser). Status Codes, GET and POST, GRPC, file transfers.

Right now, I have it set up so that the initiator for the connection does a peerConnection.restartIce(); if the peerConnection.iceConnectionState is failed or disconnected when peerConnection.oniceconnectionstatechange is triggered. This triggers a peerConnection.onnegotiationneeded event where I handle sending a new offer as the start of renegotiation which is then followed up by the initial negotiation steps.

The problem is that after all of this, the remote streams for both peers are frozen where they were when the webRTC failure happened. Does anyone know how to handle this so that the remote streams continue playing after recovery? If possible, I would like to do this without setting up new peer connections as it would be simpler.

cross-posted from: https://lemmy.bestiver.se/post/1014657

Comments

Holy gracious smokes... And almost all the background is in <canvas> (ThreeJs)!
I see they use Vite!

- The interactive sublime Planet on ~70% scroll (Operations);
- So peaceful, lovely background on ~80% scroll (Finance);
- So magnificent Golden Key on ~85% scroll (Shipping);
- The Cube on ~90% scroll (Developer)...

Colossal, marvelous, ineffably incredible work...
Indeed... no... dear... words...

"A cryptographic system should be secure even if everything about the system, except the key, is public knowledge.” — Auguste Kerckhoffs

To develop a webapp promising to the user his privacy and that his personal data will never leave his device, I first looked around but ended up building my own solution (without AI) so that it would do all this but also, allow to authenticate users on the server without compromising on their privacy.

NB: in our case user data is very sensitive; users are on the app not only to track news, prices or get alerted when a market moves, but also and mostly their portfolio worth (crypto, fiat, metals, shares,etc) and their transaction history.

Here is how it works :

• Upon creating a new portfolio the webcrypto javascript API is used to create two pairs of RSA Keys. One to wrap / unwrap, one to verify / sign, along with a hash string to uniquely identify the portfolio (rather than the user). NB: the user can also import & use his own keys.

• Optional : the user can add encryption (so that its data will be stored in his browser database - indexedDB - encrypted). If so he has to enter a password (not recoverable). This password is used only to encrypt the keys of the portfolio in the browser database. NB: the user can chose to not use browser memory and instead (manually) backup his data as a file (encrypted or not).

• Optional : at the last step of portfolio creation, the verify key is sent to the app server along with a hash string (the portfolio id in the server database)

• When adding data to his portfolio (and to indexedDB for storage) : a random single use (by key/value in indexedDB store) AES key is created to encrypt the value string, that key is then wrapped with the RSA wrap key & saved along the encrypted object in indexedDB.

• To retrieve from indexedDB : the user gets a password prompt, the password decrypts the unwrap RSA key that will unwrap the AES key that will decrypt the encrypted object back to a string (and json).

NB: Why this hybrid encryption ? Because RSA encrypt/decrypt keys can only deal with very short strings and, although it has no use for us for now, we want the portfolio to have a public encrypt key so that it can (in the future) receive encrypted message from the server or from other users (process will be the same, wrapping an AES key to be sent along the, here stringified, encrypted object).

• To authenticate the portfolio server side (work in progress as not required for now = all the gates are open, no limit on searches, on tracking prices of cryptos & fiats not listed in kraken) : requests to the server that need to authenticate the portfolio will post the hash of the portfolio signed by the RSA key - password prompt first to decrypt sign key - and server will verify the signature before answering the request.

NB: users can chose to have the webapp remember the password for some time or the full session, which allow the private keys to remain in javascript memory, as a property of a const (not exactly global as the js of the app is wrapped in an anonymous function).

I don't believe it is possible to make encrypted portfolio recoverable in case of password loss unless storing the portfolio private unwrap key on the server.... Which would defeat the initial purpose.

Anyhow, would love your feedback (& I mean criticisms!).

All the best

To see this no sign up required process in action => https://kapkap.app/

The one where I mourn the best runtime and speculate idly

Built a collection of developer tools that work directly in the browser without accounts:

1. Password Strength Checker — entropy analysis and crack time estimates
2. Privacy Exposure Scanner — shows what websites know about your browser
3. Website Down Checker — is it down for everyone or just you?
4. Security Scanner — SSL, headers, DNS audit for any domain
5. JSON Diff — compare two JSON objects side by side
6. Regex Tester — real-time matching with capture groups
7. Cron Explainer — plain English from cron expressions
8. JWT Debugger — decode tokens client-side
9. Sats Calculator — BTC/sats/USD conversion
10. Free API Directory — curated list of no-key-required APIs
11. REST API Hub — 30 endpoints for SSL, DNS, crypto, hashing, and more

All client-side where possible. No tracking, no analytics. Runs on a $5 VPS.

Compiled the curl flags I use most for API debugging. Highlights:

• -w flag for detailed timing (shows DNS, TLS, and server processing time separately)
• --resolve for testing against specific IPs without changing DNS
• --retry with exponential backoff for flaky endpoints
• .curlrc for default settings

The timing breakdown alone has saved me hours of debugging — you immediately see whether the bottleneck is DNS resolution, TLS handshake, or actual server processing time.

Put together a list of free APIs you can use without signing up or getting an API key. Grouped by category:

Developer Tools:

• httpbin.org (request testing)
• JSONPlaceholder (fake REST API)
• ipapi.co (IP geolocation)

Crypto:

• CoinGecko (prices, market data)
• exchangerate.host (currency conversion)

Security:

• Have I Been Pwned passwords API
• Various SSL/header checkers

Data:

• wttr.in (weather JSON)
• REST Countries (country data)
• Quotable (random quotes)

Full list with curl examples: http://5.78.129.127/free-apis

Every API in the list includes a copy-pasteable curl command. No signup pages, no rate limit walls on first use.

What APIs would you add to this list?

Built some free dev tools that don't require signup:

Security Scanner — paste a URL, get a security grade (A-F) http://5.78.129.127/security-scan

JSON Diff — compare two JSON objects, see what changed http://5.78.129.127/json-diff

28 API endpoints — SSL checker, DNS lookup, email validation, hash generator, UUID, base64, JWT decode, cron explainer, and more:

curl http://5.78.129.127/api/ssl/example.com
curl http://5.78.129.127/api/hash?text=hello&algo=sha256
curl http://5.78.129.127/api/jwt/decode?token=eyJ...

Free: 50 requests/day. Need more? Pay with Lightning sats.

Full docs: http://5.78.129.127/api/

You know those tasks that aren't complex enough to justify a dependency but annoying enough to keep reimplementing?

• Validate an email address (syntax + MX records + disposable check)
• Decode a JWT without installing a library
• Look up DNS records
• Check SSL certificate expiry
• Generate a QR code
• Convert between base64 and text
• Explain a cron expression in plain English

Built a simple REST API that handles all of these. Returns JSON, works with curl, no auth needed for 50 req/day.

# Quick examples
curl http://5.78.129.127/api/email/validate/test@gmail.com
curl http://5.78.129.127/api/jwt/decode?token=eyJ...
curl http://5.78.129.127/api/dns/lookup/github.com
curl http://5.78.129.127/api/cron/explain?expr=0+9+*+*+1-5

28 endpoints total. Docs at http://5.78.129.127/api/

It's not trying to compete with Postman or anything — it's more like a swiss army knife for when you need a quick answer and don't want to install anything.

Have you ever opened an old project and thought, “Why on earth was this done like this?”

And then… a few minutes later… realized you were the one who wrote it?

I ran into this while digging through an old Node.js app. One small bug led to another, and suddenly I was tracing through layers of “quick fixes”.. little patches that made sense in the moment but now feel like a house of cards.

It got me thinking... Adding a quick fix just to move on, knowing it wasn’t the “right” solution?

We all do it, right? Deadlines are tight, specs aren’t clear, and you just need things to work. But then…

What would you do if that same fix came back six months later as a critical bug?

Would you even remember why it was written that way?

Sometimes I feel like these fixes aren’t really about code.. they’re about pressure. Ship now. Clean later. Except…

When was the last time “later” actually happened?

And here’s another one: Do you think quick fixes are always bad, or do they have a place if used carefully?

Lately I’ve been trying to catch myself in that moment.. when a “5-minute fix” starts turning into something messier.

Do you stop and rethink at that point, or just push through and hope for the best?

I’ve started asking myself: “Would I understand this in 3 months?” If the answer is no, I try (try being the key word) to slow down a bit.

How do you feel about that approach? Too idealistic, or actually practical?

cross-posted from: https://lemmy.bestiver.se/post/992456

Comments