biokoda

44 ms·

91.
by biokoda 10y ago
It's no different from any other deployment really. You have a single actor type in your init.sql then when you send in queries you always specify the same actor. It's easier to explain if you tell me what you don't understan
92.
by biokoda 10y ago
Joins in ActorDB work great. Of course that is because we use an entirely different way of making an SQL database distributed and our joins aren't actually distributed even though the database is. Best way to solve a problem is to avoi
93.
by biokoda 10y ago
qmlweb mentioned in the article seems more interesting https://github.com/qmlweb/qmlweb
94.
by biokoda 11y ago
You have to be a group member to see...
95.
by biokoda 11y ago
It's not that difficult to break. Anything encrypted with a password is not all that secure. Someone can clone your device or by using a security hole in the device can get to that storage blob and eventually crack it in reasonable tim
96.
by biokoda 11y ago
The only text/voip app that securely stores its data is Biocoded ( https://biocoded.com/home ). Even if the local on-device database gets copied elsewhere, it will be undecryptable outside of that device.
97.
by biokoda 11y ago
That's a silly and un-applicable example. How many tire startups are there?
98.
by biokoda 11y ago
Distributed KV store based on rocksdb. Isn't that just reinventing the wheel? Is the fact that it is written in Rust that important?
99.
by biokoda 11y ago
If they can deliver truly cross platform GUI toolkit it would be huge. No one has quite pulled it off yet. But frankly the task is so large it is hard to have much hope.
100.
ActorDB – the ideal datastore for microservices(blog.biokoda.com)
5 points by biokoda 11y ago|0 comments
101.
Your code follows your data model. Fight the monolith with your database(blog.biokoda.com)
4 points by biokoda 11y ago|1 comments
102.
by biokoda 11y ago
ActorDB can have multiple actor types, each with a completely different schema. I would create a new actor type for this purpose and have a single actor in it. This would just contain the names of users. It would be easy to query and manage
103.
by biokoda 11y ago
We eat our own dog food and use ActorDB for everything we do. Things that are critical for the company. Multiple products are using it without issue.
104.
by biokoda 11y ago
> Furthermore, let's assume each module is its own actor and uses its own backend database. I would have every module an actor type. There can be multiple types each type has its own schema. Within an actor type many actors. An acto
105.
by biokoda 11y ago
I have no experience in developing in ERP systems. I do have experience on being at the end of a very poorly working one. These systems seem (from my outside view) to have a tendency to become giant monoliths. So when developing you must fi
106.
by biokoda 11y ago
By finding the natural sharding factor. If you have one, which very often you do. Three completely different examples: - Are you running a mail server? Every user is an actor (i.e. an sqlite instance). - Are you running a backend for a drop
107.
by biokoda 11y ago
https://www.usenix.org/conference/osdi14/technical-sessions/...
108.
by biokoda 11y ago
You can actually get very far by not sharding. But it forces you to eventually throw out everything that makes relational databases awesome and turn it into a glorified KV store.
109.
by biokoda 11y ago
Yes ActorDB takes sqlite3.c, takes out the wal.c code and replaces it with calls to LMDB. There is no redo log, LMDB is designed in such a way that it does not require it. It is actually verified as the safest storage engine design out ther
110.
by biokoda 11y ago
Well put.
111.
by biokoda 11y ago
It would perform well with one actor when compared to a single SQLite instance. Not compared to PostgreSQL/MySQL due to the concurrency model being optimized for many concurrent actors, not concurrent access to a single actor. A single
112.
by biokoda 11y ago
ActorDB takes this about 100 steps further. It replicates the actual WAL pages instead of SQL commands. So the leader executes the SQL, followers just write the pages from leader. https://github.com/biokoda/actordb It
113.
by biokoda 11y ago
That was the reason Erlang was created in the first place: https://en.wikipedia.org/wiki/Erlang_%28programming_language...
114.
by biokoda 11y ago
Either GPL so can't be used commercially, or they do not have both android and ios support.
115.
by biokoda 11y ago
It's very unfortunate libsound does not have iOS/Android support. So much development is on those platforms at the moment and nothing good is available. Whereas there are a number of high quality desktop libraries anyone can use.
116.
by biokoda 11y ago
Nim seems to be doing pretty well and it compiles to C. I've not really used it but it does look pretty good.
117.
by biokoda 11y ago
Ehm no not even close.
118.
by biokoda 11y ago
A complete client side code rewrite to get rid of something is pretty much married to it.
119.
by biokoda 11y ago
Because it implies running on top of a VM and much worse rendering data through HTML/css.
120.
by biokoda 11y ago
> Neither of these is unfixable over time JS on desktop is never going to perform well.

More ›