
Fractalide: Simple Rust Microservices - dmmalam
https://github.com/fractalide/fractalide
======
setori88
An author here: we're working on the nixcrates project to remove cargo and
allow for closer integration between nix and crates.io, so far you can check
out the project at
[https://github.com/nixcloud/nixcrates](https://github.com/nixcloud/nixcrates)
(joachim and paul are super people, hit them up if you're interested in
contracting them) the net/http stuff is currently incompatible with the most
recent changeset, I'll get working on it tomorrow morning HKT to make it work,
I have to refactor it to suit the new stabilized API. Anyway, this attention
was a bit earlier than expected, still have a couple of weeks to go before
stabilizing. I hope you guys can kick the tires, tell us what you don't
understand and please comment on the API because we want something sensible.
We're using the late Pieter Hintjens' C4 so please hop on board and
collaborate!

~~~
brohee
Why do you have "remove cargo" in your roadmap?

~~~
setori88
There is too much cognitive dissonance between nix and cargo. It might be
better to get nix, a package manager, to do the job of cargo, a package
manager.

------
akubera
Most documentation is in the form of README files within the subdirectories;
here is the code auto-docs:
[https://docs.rs/fractalide](https://docs.rs/fractalide)

Looks like knowledge of the nix distribution system is required to use. I
don't know how hard it would be, but a neat auxiliary project would be a cargo
plugin that supports fetching packages though nix.

The "net/http" fractal definition [0] references the repository
[https://github.com/fractalide/fractal_net_http](https://github.com/fractalide/fractal_net_http),
which is where the rust microservice code actualy lives.

There is an example TODO app in the
[https://github.com/fractalide](https://github.com/fractalide) root dir (split
between fractal_app_todo_{,model,controller}).

Upon further inspection, this seems to be "simple nix microservices" that
happen to be implemented in rust. One of the goals is to "remove cargo", and
they use `nix-build` over `cargo build`. Also, a lot of implementation is in
their 'flowscript' language within a lot of *.nix files [1] [2].

Interesting project nonetheless. Good luck to them!

[0]:
[https://gitlab.com/fractalide/fractalide/blob/master/fractal...](https://gitlab.com/fractalide/fractalide/blob/master/fractals/net/http/default.nix)

[1]:
[https://github.com/fractalide/fractal_app_todo/blob/master/c...](https://github.com/fractalide/fractal_app_todo/blob/master/components/todo/patch/default.nix)

[2]:
[https://github.com/fractalide/fractal_app_todo/blob/master/c...](https://github.com/fractalide/fractal_app_todo/blob/master/contracts/todo/default.nix)

------
buckhx
Not to discount any of the work being done here, but I'd love to see a stable
rust grpc implementation.

~~~
eclark
Same. Right now rust feels pretty isolated on the network. There's no great
RPC support. No thrift, grpc, etc. The http libraries are good for low level,
unsecured, stateless services. However they lack lots of more complex
features.

~~~
steveklabnik
What do you think of Capn' proto?

~~~
jupp0r
It's very different to grpc, lacking streaming semantics but offering
capabilities, which are certaintly nice.

~~~
dwrensha
True, streaming is not a baked-in feature of Cap'n Proto. Streaming can,
however, be implemented on top of capabilities, as with this ByteStream
interface: [https://github.com/sandstorm-
io/sandstorm/blob/v0.197/src/sa...](https://github.com/sandstorm-
io/sandstorm/blob/v0.197/src/sandstorm/util.capnp#L69-L117)

------
vegabook
Looks incredible. I for one cannot encourage enough, dataflow competitors to
the current JVM lockdown on this space. A few questions:

a) will Fractalide support dynamic dataflow graph change at runtime?

b) For reasons of clarifying your objectives further, could you elaborate on
your target market's current occupants? Is this Kafka / Flink for Rust?

c) What is your estimated timeframe for a feature-credible, testable release,
even if beta?

~~~
setori88
a) yes it will, we'll have to do some design on the `fvm` to make it hotswap.
It won't be ready for this stabilization release. The functionality is already
there it just needs

b) I'm not really focusing on other market occupants. We need this system to
solve some pretty hairy problems 100TB problems.

c) 'feature-credible, testable release' primarily this is dependent on
`nixcrates`, documentation and maybe getting a few more services examples. I'd
say a couple of weeks.

