You're right there are other use cases besides microservices. For me, the other exciting application is to use Tuna in an analytics tool. The beauty would be that you don't have to use any query language to analyze large datasets.
With regards to orchestration, I hope to add primitives for events, batch processing, and things like that.
Make sure I understand your question correctly: You're asking how updates will work so:
-old deployments don't see the next version's types coming out of global state
-new deployments only see valid types.
I believe the compiler can do a lot of heavy lifting for updates while still remaining flexible. The compiler could take in two tuna files and type check across versions. For example, imagine two version of the same application. In v0 we store Foo. In v1 we store Bar.
A couple options open up:
- We can deploy v1 but a transformation from Foo to Bar must be executed across all stored data. This would need to be performed while v0 is down.
- We can deploy a type safe version of v0 and v1 that handle the union Foo or Bar. Then, we can teardown the type safe version of v0. v1 should be the only deployment that migrates foos to bars. The benefits of this approach is that you have non disruptive upgrades.
Hi all, I'm Jeremy, and I’m excited to be sharing Tuna. I built this because I wanted to develop scalable web services as quickly as possible. I was tired of cobbling together containers, databases, web servers, build tools, and the what-have-you in order to build scalable applications. In Tuna, you can create a stateful web service in just 4 lines of code with zero application-land dependencies.
Compared to other programming languages, Tuna is unique because the global state is stored in a database. Under the hood, Tuna compiles to an intermediate representation that I also created called Conder: https://github.com/Conder-Systems/conder. This intermediate representation is decoupled from any specific storage provider. When it is compiled, query optimizations are applied to the IR to improve performance.
My hope with Tuna and Conder is to simplify building scalable, secure, and vendor-agnostic distributed systems.
With regards to orchestration, I hope to add primitives for events, batch processing, and things like that.
Make sure I understand your question correctly: You're asking how updates will work so: -old deployments don't see the next version's types coming out of global state -new deployments only see valid types.
I believe the compiler can do a lot of heavy lifting for updates while still remaining flexible. The compiler could take in two tuna files and type check across versions. For example, imagine two version of the same application. In v0 we store Foo. In v1 we store Bar.
A couple options open up: - We can deploy v1 but a transformation from Foo to Bar must be executed across all stored data. This would need to be performed while v0 is down. - We can deploy a type safe version of v0 and v1 that handle the union Foo or Bar. Then, we can teardown the type safe version of v0. v1 should be the only deployment that migrates foos to bars. The benefits of this approach is that you have non disruptive upgrades.