ledgerdev

Awesome answer, thanks! Foundation seems like magic almost, from just choosing very smart trade offs and co-ordination.

I was just looking into this, and found this really interesting post about foundationdb and sql.

https://www.voltactivedata.com/blog/2015/04/foundationdbs-le...

Also this, excellent comparison of distributed database consistency methods, mentions cockroach, but not foundation. http://dbmsmusings.blogspot.com/2018/09/newsql-database-syst...

This brings up the question, what method/protocol does foundation use for distributed consistency?

listen/notify

edit: https://github.com/cockroachdb/cockroach/issues/41522

> yet a another example of how C# is becoming a dominant systems language

Perhaps a bit of a stretch. I am currently choose golang for a more systems like project because of startup time and gc pauses in c#/dotnet. Definitely nice to see nativeaot which should address the startup time issues.

Ok, so turns out default chrome/firefox on windows/android were not issuing the history refresh request on back button click. Turns out you need to add some additional config to make that happen. It's now working, and it's excellent.

Set htmx to not cache prior pages by setting `htmx.config.historyCacheSize = 0` in window.onload.

Also set the http caching header `cache-control: no-cache`

Data Oriented Programming. In short, don't entangle your code with data, and the data should immutable.

https://blog.klipse.tech/databook/2020/09/25/data-book-chap0...

> 2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout. Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state.

The problem is that when you press back button in the browser, it doesn't make another request to the server. It reloads the page from browser memory. A link back can be made to work, but that's not what I was speaking to.

I tested the most trivial case, when you return a response, and push navigate to next step, then press browser back button, form state is not retained. Both chrome and firefox do not restore the form state on navigation back after a url push navigation.

I don't think that without some client side JS that saves/reloads prior form state this is a solvable problem because of browser behavior. Either that, or perhaps use different divs for each step then have js hide/show them which is what I will try next but involves writing js to do so.

EDIT: tried multiple divs on same page, same behavior so that will not work.

It's pretty clear that htmx hasn't considered back button much at all, it also clobbers the page titles in history as well (https://github.com/bigskysoftware/htmx/issues/746), but that's a fixable problem.

So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button.

In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into text boxes. This is a show stopper problem and been working on work arounds, not sure any is good. Basically we have resorted to plain old full page reloads with client side redirect to resolve this.

How about IPS vs VA panels for text rendering?

Nothing totally new, but it is an attribute based extension of html that allows any element to generate http get/post and handle/target a hypermedia response back into the dom... without the need (but still have the option) to write javascript if you want. You end up writing almost zero js and it's wonderful.

There is absolutely nothing proprietary about the format. It's just plain html and vanillajs works fine if that's what you'd like to use. Hyperscript is no different than any other open source compile to js lang.

This exactly. I just started a new project with htmx this past week, and it absolutely amazing. It brings the magic of the web back we first experienced moving away from 90's windows programs. I'm a firm believer that react/angular are grossly mis-used for information based apps and websites, they should really only be used for rich client apps like chat, music players, image editors, offline, etc.

Does this have, or are there any plans for a change-feed? Has anyone used this as an event sourcing db?

My preferred method is to tokenize sensitive data before storing in the immutable logs/database.

I've always been curious, what kind of latency do you see between an insert, and when the notify goes out over the channel?

> Completely agree. I am so disheartened with how co-workers don't seem to take any issue with the aws service suspensions. They are just like oh well, it won't ever happen to us and they must have deserved it. New rule for myself when designing any system now is no cloud vendor lock in allowed.

What's the status of grpc both as client and server? I seem to recall reading somewhere that some features(trailing headers?) needed to call grpc as client were out of the fetch spec and thus would to be implemented. It's also not clear from this issue either. https://github.com/denoland/deno/issues/3326

Long term a free and open society needs a distributed and un-censorable twitter like communication protocol/medium.

Any efforts to build something like this out there?

The data consistency seems most attractive point. I'm wondering where precisely fauna clusters are located, so I could run my lambda functions in same location. What sort of latency do we see when connecting from various azure/aws datacenters? Are they in most aws data centers?

> 2) Rust's ecosystem makes it easy to find and integrate solutions not offered by the standard API

This made me think back to something Rich Hickey said in his "Are we there yet?" talk. In short rust has memory management, and so can better function as a library language, similar to how Java did back in the 90's. Rich's quote below.

>> And it is a big problem. I think the lack of garbage collection really impeded C++ in one of its design objectives, which is: it was supposed to be a library language. All the original design stuff and any time you heard Stroustrup talk about it, it is like, "C++ is going to be a library language". But it only ever ended up being a parochial library language. Every shop had a library, but there were not a library, and still are not a lot of libraries, that go between places, because of this problem.

https://github.com/matthiasn/talk-transcripts/blob/ccc4a0172...

They have a history many years back, of not being fully truthful with customers about hacking incidents. Do a google search.

relevant: https://news.ycombinator.com/item?id=5667027

Fly.io is more exciting for me because it's edge app servers and it terminates web sockets. I've been envisioning a live-view like framework, or heck even a regular old rest api, where the client connects to the fly.io server with a single request then the app server makes a request to N number of back end processing servers using an efficient protocol like grpc.

Very nice syntax, looks great.

Thanks!

What's the hosting story for crux if one wanted to try it out on a side project?

I haven't actually used wrangler yet, but will give it try :)

I love the discussion about what's the future abstraction for serverless, and love where cloudflare is headed. Can wait to see what's next. A couple questions.

Any plans to support web-sockets terminated in the isolate(not just proxied)?

Any plans for a local development? Some open source locally run-able or low volume self host-able stack that mirrors the global stack would I think really help dev workflow and adoption.

edit: just poking around their blog saw this. https://blog.cloudflare.com/making-magic-reimagining-develop...

Node+NPM isn't going anywhere, but Deno sure seems like the server based runtime of the future.