I never thought of this, but now I have a lot of questions. Do you have an application in mind where this would be useful? Most of my experience if with traditional webapps/SaaS so I'd love to see an example.
Ask HN: Options for handling state at the edge?
11–20 of 40 posts
Re: Ask HN: Options for handling state at the edge?
#12I don't have a whole lot to say on this right now (very WIP), but I have a strong belief that git is a core tool we should be using for data. Most data-formats are thick-formats, pack data into a single file. Part of the effort in switching to git would be a shift to trying to unpack our data, to really make use of the file system to store fine grained pieces of data. It's been around for a while, but Irmin[1] (writt…
You really want to use CRDTs, not data types subject to human resolved merge conflicts.
Re: Ask HN: Options for handling state at the edge?
#13I recently had an opportunity to build an application on top of Lambda@Edge (AWS's equivalent of Cloudflare workers). The prevailing wisdom there was to make use of regional services, like S3 and DynamoDB, from the edge. That, of course, makes my edge application depend on calls to a larger, further away point of presence. While it's possible to distribute state to many AWS regions and select the closest one, I ended…
Isn't this effectively the same as using a static site generator? Could you potentially freeze or pre-bake your generated files and then just serve that?
Re: Ask HN: Options for handling state at the edge?
#14I don't have a whole lot to say on this right now (very WIP), but I have a strong belief that git is a core tool we should be using for data. Most data-formats are thick-formats, pack data into a single file. Part of the effort in switching to git would be a shift to trying to unpack our data, to really make use of the file system to store fine grained pieces of data. It's been around for a while, but Irmin[1] (writt…
You really want to use CRDTs, not data types subject to human resolved merge conflicts.
I feel like crdts are sold as a panacea. I can esily imagine users making conflicting changes, so I dont really see or understand what the real value or weaknesses of CRDTs are.
Im also used to seeing them used for online synchronization, & far less examples of distributed crdts, which is, to me, highly important.
Git by contrast has straightforward & good merge strategies. At this point, I feel like the problems are complex & that we need complex tools that leave users & devs in charge & steering. Im so ready to be wrong, but I dont feel like these problems are outsmartable; crdts have always felt like they try to define a too limited world. For now, I feel like tools for managing files between different fs'es are more complex, but a minimum level of possibility we need.
Re: Ask HN: Options for handling state at the edge?
#15I haven't done this, but I've been thinking about it lately. Fly.IO has had some very interesting ideas on this if you want to use a relational database. There was an article about litestream that would allow you to replicate your SQLite database to an arbitrary number of nodes, which means that every application server would have a SQLite file sitting on it for read queries, and then you can capture write queries and forward them to a write leader and let that user continue talking to that server until it replicates across your application servers.
You can do basically the same idea with any relational database, have a write leader... somewhere and a bunch of read replicas that live close to the edge.
There's also what you would call cloud native data stores that purport to solve the same issue, but I don't know much about how they work because I much prefer working w/ relational databases and most of those are NoSQL. And I haven't had to actually solve the problem yet for work so I also haven't made any compromises yet in how I explore it.
Another interesting way to go might be CockroachDB. It's wire compatible w/ PostgreSQL and supposedly automatically clusters and shares data in the cluster. I don't know very much about it but it seems to be becoming more and more popular and many ORMs seem to have an adapter to support it. May also be worth looking into because if it works as advertised you can get an RBDMS that you can deploy to an arbitrary number of places and then configure to talk to one another and not have to worry about replicating the data or routing correctly to write leaders and all that.
And again, I'm technical, but I haven't solved these problems so consider the above to be a jumping off point and take nothing as gospel.
Re: Ask HN: Options for handling state at the edge?
#16Doesn't Cloudflare have a cache API and/or cache fetch calls for workers?
A number of people are talking about Lambda or loading files, SQLite, etc. These aren't likely to work on CF. CF uses isolated JavaScript sandboxes. You're not guaranteed to have two workers accessing the same memory space.
This is, in general, the problem with serverless. The model of computing is proprietary and very much about the fine print details.
edit: CF just announced their SQLite worker service/API today: https://blog.cloudflare.com/introducing-d1/
Re: Ask HN: Options for handling state at the edge?
#17CloudFlare just announced their own relational DB for workers today: https://blog.cloudflare.com/introducing-d1
Re: Ask HN: Options for handling state at the edge?
#18AWS Lambda functions have a local temp directory. I have successfully used that in the past to store state.
In my application, I had a central worker process that would ingest state updates and would periodically serialize the data to a MySQL database file, adding indexes and so forth and then uploading a versioned file to S3.
My Lambda workers would check for updates to the database, downloading the latest version to the local temp directory if there was not a local copy or if the local copy was out of date.
Then the work of checking state was just a database query.
You can tune timings etc to whatever your app can tolerate.
In my case the problem was fairly easy since state updates only occurred centrally; I could publish and pull updates at my leisure.
If I had needed distributed state updates I would have just made the change locally without bumping version, and then send a message (SNS or SQS) to the central state maintainer for commit and let the publication process handle versioning and distribution.
Re: Ask HN: Options for handling state at the edge?
#19I have used card database files before with success. https://cr.yp.to/cdb.html Have your process regularly update the CDB file from a blob store like S3. Any deltas can be pulled from S3 or you can use a message bus if the changes are small. Every so often pull the latest CDB down and start aggregating deltas again. CDB performs great and can scale to multiple GBs.
I thought it was "constant database"? Is it indeed meant to mean "card database"?
my typo thanks for catching that
Re: Ask HN: Options for handling state at the edge?
#20Check out Macrometa, a data platform that uses CRDTs to manage state a N number of pops and also does real time event processing. - https://macrometa.com (full disclosure, I work at Macrometa)