BackBlast

I find that moving the full query system into the front end is where most front end devs really want to be. They want a full power query system for the data instead of continuous rounds of re-inventing the transport layer, REST, GraphQL, *RPC, etc.

It's hard to adopt such a system in most traditional web shops with their specialized backend and frontend teams. You're pulling out the database, backend, transport, and auth layers and replacing them with this single block system. Most system architects grew up in the backend so they are generally pretty ignorant of this issue. As it touches both sides extensively you're probably not fitting this into an existing system, which leaves only green field new development. Finally your backend is not an AWS or Asure service, neither is it lambda friendly. All of this means that most architect types I talk to will never touch it.

This style of system mostly already exists with old tech, CouchDB+PouchDB. Which works pretty well for some things. The downsides are that the query system isn't really ideal and the auth and data scoping system is pretty foreign to most people. The easiest model to work with is when the data is totally owned by a single user, and then you use the out-of-the-box database-per-user model. High data segmentation with CRDTs removes a lot of conflict issues.

It has scaling issues though, CouchDB has really high CPU requirements when you're connecting 10k to 100k users. The tech is long in the tooth though it is maintained. On the system design side it gets really complicated when you start sharing data between users, which makes it rather unsuitable as you're just moving the complexity rather than solving it.

This approach seems to hit the same target though will likely have similar scaling issues.

Look forward to see the evolution of the system. Looks like a first step into the world.

Is it? I don't really watch movies.

But that's pretty funny to learn :) Nice.

Fly them in. Give them a driver to assist them in arriving and getting to the interview. Have the driver make an obvious mistake. Circle the block or arrive a couple of minutes late.

Auto-fail anyone who treats the driver poorly. Find the guy that wants and/or tries to help the driver succeed.

Various ways to see the inner person and not the "show person" on display for the interview.

If you use auto scaling services and fail to limit a recursive call to a service. You can create a giant explosion aimed at your bank account.

Yes, you can do it in DNS. Update the record with your new ingress, then wait for the timeout on the old record to assert itself and the new connections move over.

Not all DNS servers properly observe caching timeouts, so some customers may experience longer delays before they see it working again.

Arguably you can buy the mobile variants of the Ryzen 7000 series, like 7940HS/7840HS, as a package, cheaper per core than the 7950X. Depending on the use case it may be a better fit. Definitely if footprint and/or power consumption are main drivers it may be much better.

If you need the I/O or full ECC of the bigger systems then you just need the bigger systems.

Won't be winner takes all. The people who use local models will have requirements or desires that lean them that way. The rest will use the easier to stand up large corp offerings.

Only way this changes is if there is a very large performance gap between the two. Small ones just won't matter.

Probably an unpleasant conversation with the board. Resign, or be fired.

This is very likely covered in the contract to begin with so there isn't much room for negotiation unless the board feels he's breached some significant contract term.

Nice to see a company really try to make it right.

nim+httpbeast is a multi threaded library by default. Node, bun are effectively single threaded. A cursory search indicates that the go library is single threaded by default.

So the nim comparison is a bit of apples and oranges.

Also, the usual caveats of running micro benchmarks against localhost on an auto scaling CPU core...

> 1. Most software 'engineers' are more like technicians, plugging libraries into each other

You didn't mine, smelt, and manufacture the raw material yourself? Sorry, not an 'engineer', technician only. You're using other people's stuff to do your thing.

If you want the GPIO, that's a good reason to go Pi. Nothing equal to the software support inside the raspberry pi eco system for it's embedded controls.

If you want a small PC for media/homelab server/cheap desktop, they don't make any real sense anymore.

He's talking about off the shelf PCs, not Arm based SBCs with a wonky software stack.

Something to keep in mind is that all of the tables are only trying to measure one thing and lay out the effect of the one variable. But in reality these can be mixed and matched for the desired performance characteristics. 10x is indeed possible by doing multiple things to extend the life of the cell.

Pull 4x from one table and 2-3x from another and it would probably put you somewhere in the 10x range. Though I'm not sure it would be strictly multiplicative.

The top end charge voltage is particularly sensitive, this is the most chemically unstable state of the cell charge cycle.

I really wish cell phones and computers came with an adjustment to max cell voltage. Cutting even 10% capacity can double your cycle life. Some do, but it's a hodgepodge and not standard.

https://batteryuniversity.com/article/bu-808-how-to-prolong-...

Realistically, they are constrained by how many birds they can put in the sky. More people would sign up if the performance was better.

They've been overly optimistic about launch capacity. Typical Musk company optimism. Still, it's a success at building out a new market.

Would be nice if systems offered more bifurcation. An NVMe SSD on pcie 4 could easily run off 2 lanes and be fine. 1 lane for 5.

You lose a bit of top end transfer that shows up in the benchmarks, but it's near impossible to tell.

> How would you sell Node to other old guys? Especially compared to Go.

JavaScript has a huge business case in the front-end. Going another direction is possible, but you're really fighting against the grain to do so.

Go node/bun/deno and you can build back-end and front-end with one language. This has pretty significant advantages. Particularly if your goal is small teams (or solo) with "full stack" style devs. There are fewer siloed specialists required in the org.

Language concepts, syntax and patterns are a significant part of the cognitive load needed to develop.

If you're in a siloed org with specialists anyway, there is minimal draw.

I've done things like have a backend I brought into the front end to mock an immature system. Shared code between the back end and front end for offline-first systems. You just can't do that kind of stuff when you don't share a language between front-end/back-end.

> The storage is expandable externally

I have tried a variety of methods of expanding the storage. I bought an M1 system with this very thought.

None of the USB storage devices I tried worked well. MacOS drops every device I tried periodically. Sometimes it would go as long as a week, but I'd have to yank it and plug it back in for it to continue to work. Very unreliable for a permanent storage augmentation.

NFS doesn't work, MacOS issues. Samba has been the most reliable network storage drive method, but it tends to be slow on my middling servers - and I really tried to optimize it.

If you really want to do this, I suggest trying the thunderbolt route.

"Hey, we aren't seeing results from TDD."

"It must be the bad attitudes on the team."

Or... TDD just isn't the panacea it's proponents make it out to be?

Sabrent has a 8TB M.2 as well. It's expensive.

Enterprise space can be reasonable to look at.

7.68TB $400, similar to the QVO but much better quality flash and interface.

https://serverpartdeals.com/collections/solid-state-drives/p...

It is U.2, so you'll need an adapter.

Have you not noticed that SSD prices have dropped by almost half the last 6-8 months?

I can get the same SSD I bought in February for literally half the cost today.

You can get larger drives. 4TB has pretty high availability. If you want more, you can go server grade U.2 and get 8-32TB SSD - you will pay more though.

I built a very similar setup for my kids. Mine operates per-system, some are white listed with individual settings, and my oldest are on a blacklist only for problem sites.

Thanks for sharing.

Children don't get their own phones till they are ~16 and have more independence. They need them at some point, but too early is like giving a child crack.

We have a family flip phone that I can give out as needed when a child is going somewhere and we want to be able to contact them and vice versa.

Gabb wireless is also a good option.

> No, but I've definitely seen bespoke, hand-rolled frontend code do it, and that's what you're comparing SPAs to on the server side.

Yes, congratulations, you pointed out that you can hang yourself either way. That wasn't my point and I acknowledged as much in the first post.

One has an unsanitized escape free method and the other does not.

You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential.

Everything rendered by the server has this potential as it must be deserialized by the browser.

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering.

You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes.

Which is why you shouldn't roll your own SSR unless you are fully aware of this.

SPA doesn't have this problem as it will generally insert DB data into the DOM as text, no possibility of escape or execution by potentially malicious database entries. Not that you can't have issues in an SPA, but you have to do work to bring them about.

> Facing massive datacenter costs, ...Other companies with large datacenter costs followed suit, many monies were saved.

I can't think of anyone who doesn't want to save money on servers. Seems like a pretty good general win to me for using the client.

> complexity is generally the enemy

Agreed. But minimizing complexity doesn't require not using a heavy client. You can go fully the other way and make the backend a relatively simple permissions and validation mask on top of a database and let the front end hold all the relevant state.

Use client side rendering and have simplicity too.

I will admit that an SPA turns out to be easier to mess up and design really poorly, but I believe that this is a tooling maturity issue rather than fundamental to the platform. SSR frameworks have had over a decade longer to mature.

Tried the latest version. Axios is broken. But that's an improvement from the last time I tried to run one of my backends. I'll keep an eye on your progress.

> If you want proper serverless, you have to pick a vendor you trust and stick with them.

Some of us have to consider platform risk in our designs and not just ignore it. This is what makes lock-in an issue in the first place. Some times, well, most of the time it isn't an issue. But when it is, it's a huge potentially-company-destroying issue.

Different companies have different risk profiles, and it may be perfectly fine for many to just ignore this risk while others, quite reasonably, have to consider it.

> It was often ridiculed, but the goal made sense. What is the vision for twitter? I still don’t know. Nothing he says makes any sense.

You're missing the core. He wants Twitter to be a functional and inclusive town square for public, and world wide, discussion.

There is the bot and manipulation problem. Which is deeper and more extensive than anyone seems to really believe. Frankly, I'm not sure how anyone solves this without pretty stiff vetting during on boarding. Any community that provides free signups is going to have bot problems. Period. Facebook is losing this war. So is Google.

I think he should punt the prevention of AI data scraping as not worth the cost. But it's value he is leaving on the table if he doesn't, though I think this one is detrimental to the users. Put it in the EULA or content licensing or where ever and be satisfied. Don't throw it in front of your legit users.