Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Guy Youansi
    @ralphlaude
    @Gryfit thanks for the details. i will ask another question. which language do you use for your service? could you also provide the implementation of your service?
    Bartek Tonia
    @Gryfit
    Thanks for interest, Java - spring plugin, as for implementation:
    Springbootapp
            new CloudState()
                    .registerEventSourcedEntity(
                            TestEntity.class,
                            Deviceservice.getDescriptor().findServiceByName("TestEntity"),
                            wirelessmesh.persistence.Domain.getDescriptor())
                    .start()
                    .toCompletableFuture()
                    .get();
    request fot entity
        @RequestMapping(value = "/get-state", method = POST, consumes = MediaType.APPLICATION_JSON_VALUE)
        public ResponseEntity<Object> createProduct(@RequestBody KafkaUpdateRequest cmd) {
            ManagedChannel channel = ManagedChannelBuilder.forAddress("0.0.0.0", 8080)
                    .usePlaintext()
                    .build();
    
            TestEntityGrpc.TestEntityBlockingStub stub
                    = TestEntityGrpc.newBlockingStub(channel);
    
            Iterator<Deviceservice.State> state = stub.getState(Deviceservice.GetCommand.newBuilder()
                    .setId("xd")
                    .build());
    
            String s = state.next().getState();
            channel.shutdown();
    
            return new ResponseEntity<>(s, HttpStatus.ACCEPTED);
        }
    entity
    @EventSourcedEntity
    public class TestEntity {
        /**
         * Unique identifier for this entity, also just happens to be the same as deviceId.
         */
        private final String id;
    
        private String state = "state";
    
        /**
         * Constructor.
         * @param entityId The entity id will be the deviceId.
         */
        public TestEntity(@EntityId String entityId) {
            this.id = entityId;
        }
    
        @CommandHandler
        public Deviceservice.State getState(Deviceservice.GetCommand cmd, CommandContext ctx) {
            return Deviceservice.State.newBuilder().setState(this.state).build();
        }
    
        @CommandHandler
        public Deviceservice.Empty setState(Deviceservice.SetCommand cmd, CommandContext ctx) {
            ctx.emit(Domain.StateSet.newBuilder()
                    .setId(cmd.getId())
                    .setState(cmd.getState()).build());
    
            return Deviceservice.Empty.getDefaultInstance();
        }
    
        @EventHandler
        public void stateSetHandler(Domain.StateSet ss) {
            state = ss.getState();
        }
    
    }
    Bartek Tonia
    @Gryfit
    for a bit older version you can also checkout https://github.com/Gryfit/cloud-test
    Bartek Tonia
    @Gryfit
    @ralphlaude
    Bartek Tonia
    @Gryfit
    • Do I have to use Cassandra for event sourceing? or can I use inMemory
    Guy Youansi
    @ralphlaude
    @Gryfit you can use whatever store (in-memeory, postgres or cassandra) you want for event sourcing. samples are here (https://github.com/cloudstateio/cloudstate/tree/master/samples/js-shopping-cart) and for postgres here (https://github.com/cloudstateio/cloudstate/blob/master/samples/js-shopping-cart/postgres-store.yaml)
    Marcel Lanz
    @marcellanz
    cloudstate.proxy.journal-enabled has to be configured if the proxy should support cloudstate.eventsourced.EventSourced
    the proxy otherwise will not offer ther event sourced model be supported. Which directly leads to the error messages above.
    Adriano Santos
    @sleipnir
    Hi @Gryfit As @marcellanz said you need to enable the journal for the proxy to work. I noticed in your repository that you are using spring directly with java-support as a dependency. I suggest you use the integrated spring support, maybe that makes things a little easier for you https://cloudstate.io/old/docs/springboot/current/
    Adriano Santos
    @sleipnir
    @Gryfit take a look Gryfit/cloud-test#1
    Ryan Hanks
    @ryanhanks

    Hey everyone. At the last contributor's call we were discussing Scala support for user functions, and one approach we're looking involves making use of Scala code generation (driven off the proto definitions for an entity service) to provide underlying functionality to inherit from when providing the actual implementations for user functions.

    When we discussed code generation, the conversation headed in the direction of a build process. In a Scala-only, the first place we turn to as a potential tool for the job is SBT.

    It was then mentioned that if we find languages other than Scala that would also like to tap into a somewhat similar set code generation capabilities, we may benefit from having a tool with the potential to support multiple languages. The build tool Bazel was identified as a good potential candidate for this task.

    So, when it comes to moving the Scala language support forward, we have a few related questions that would be good to find answers to:

    1. Will there be more than one supported language that is eventually interested in making use of some kind of code generation?
    2. When considering approaches for driving code generation for Scala language support, should we consider a tool other than SBT for right now? SBT may be the easiest way to get something quick out there, but maybe this is worth taking a little time for.
    3. Do we want to pursue a build tool that supports more than one (many? all?) language(s)? The answer to this one could be yes independent of whether or not multiple languages are interested the code-generation route.

    Are there people in particular that would be good to reach out to for input on this?

    Are there other questions I can add to this list that we should also be asking in this same discussion? Do we need a more thorough investigation into Bazel before we can answer these questions?

    Happy to take input on this at the upcoming contributors call in ~ T minus 1h. Hope to see you all there.

    CC: @pvlugter

    Viktor Klang (√)
    @viktorklang
    For code generation it would seem like using protoc plugins would be the idiomatic way?
    Adriano Santos
    @sleipnir
    Hello I think that all languages ​​would benefit from having a project builder, I tried an approach with cloudstate cli based on templates that I intend to expand to support dynamic templates. I think that providing the ability for simple connections between the proto and the language files is not difficult to achieve in some way. But it becomes very difficult to implement depending on how smart you want your tool to be. With Cloudstate this can be particularly difficult for some types, like CRDT for example. I think we can start with something simple, probably Bazel would be a good tool for that, and then improve. I think that if you are able to create the basic structure of directories, configuration files, dependencies, and empty classes (files) for entities you would already have an absurd gain in productivity. I am refactoring the Cloudstate CLI and one of the points that I intend to attack is the generation of code, today the tool already generates a valid example project, very similar to the ruby ​​scaffold, for most of the supported languages, but it certainly improves a lot
    Ryan Hanks
    @ryanhanks
    Right, and then if Bazel is in the picture, it would come into play in driving the protoc execution. But are you suggesting that bazel might not be needed? @viktorklang
    Adriano Santos
    @sleipnir
    I think going to protoc now would be kind of complex
    I don't think we need the protoc. You need to run the protoc at some point to get the classes, but you can build everything else with simpler tools
    Ryan Hanks
    @ryanhanks
    One appeal of living in the protoc world (if I'm understanding things correctly) is that it introduces an interface for defining code generation plugins that happens to prove to be very useful in driving the kind of code generation we might want to do (at least in the scala world): CodeGeneratorRequest (https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/compiler/plugin.proto#L68). Maybe protoc isn't the only way to generate instances of this CodeGeneratorRequest object, and maybe it's also not the perfect interface for driving the code generation we'd like to do, but this interface does contain the key information I can see needing to drive code generation for an entity service in the way we might like to do it for Scala. @sleipnir what did you have in mind when it comes to a simpler approach to generation? Would love to hear more about what data are you envisioning passing to the code-generation layer or what exploration you might have already done here. Was there a language in particular you were trying your approach with?
    Ryan Hanks
    @ryanhanks
    We could come up with our own equivalent of a CodeGeneratorRequest, if we find that something more customized meets our needs. One question I have though is how easy is it to parse a set of proto files into a set of FileDescriptorProto (https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/descriptor.proto#L62). Haven't really found an API that lets you read a set of proto files and spit out those FileDescriptorProto object, does anyone know where that exists? Or is this a job best left to protoc? Been looking for an answer to this question for a while actually..
    Adriano Santos
    @sleipnir
    It's not just about generating code, it's generating code, directory structure, configuration files (maven, gradle, sbt), and etc ... I don't see the protoc being used for this anywhere else, because we're going to write that wheel?
    Of course, I am also not against this approach, I am just presenting an argument for reflection.
    I'm being the devil's advocate
    :D
    Ryan Hanks
    @ryanhanks
    (For reference on how we might use bazel + protoc, https://github.com/Dig-Doug/rules_typescript_proto/blob/29e539777b5b49f740322c12bf7e0e5eaa008a5d/src/typescript_proto_library.bzl#L51
    is an example which defines some bazel rules that call out to protoc to generate typescript definitions. In this case, protoc then
    calls the typescript generator plugin, when gets one of those CodeGeneratorRequests: https://github.com/improbable-eng/ts-protoc-gen/blob/master/src/index.ts#L24)
    Adriano Santos
    @sleipnir
    I think this mixed approach is more promising, so we can use Bazel for everything else and the protoc to generate just code
    Ryan Hanks
    @ryanhanks
    I see. @sleipnir which language were you building for in your experimentation? Were you using a tool in particular to drive the generation?
    Adriano Santos
    @sleipnir
    I built for everyone. Cloudstate CLI is a tool for building and deploying CloudState functions written in Rust. I didn't use anything in particular, no specific code generation tool because in the current approach only an example scaffold is generated, I'm reformulating to include this code generation, but I was in the line of using template files. Bazel is a more robust (and also more complex) tool and can be a good approach to proceed
    Ryan Hanks
    @ryanhanks
    @sleipnir I see, makes sense. Need to look into the cli tool again, I gave up on it after the project I create never activated and then disappeared (sorry for the rant :) ). Does it generate a starter project for any of the supported languages?
    @sleipnir also, maybe you know, any plans for a brew recipe for that thing?
    Peter Vlugter
    @pvlugter
    Good discussion. Seems there are multiple points to consider. Hooking into the protoc plugin support for code generation sounds good, especially if that can make cross-language support easier. Then there's templating (getting started with a new project, where the cloudstate CLI has some experimentation) and scaffolding (adding templated features to an existing project). And whether we should have a full experience for the build tool as well. Akka gRPC currently maintains plugins for sbt, gradle, and maven, and Cloudstate currently has a bring-your-own-build-tool approach. But we could also look towards an experience of just writing the code, and polyglot build handled by Bazel (where maybe the CLI generates the build files automatically).
    Adriano Santos
    @sleipnir
    interesting point Peter.
    @ryanhanks Basically the current CLI downloads the templates from a git repository and applies the name and path changes and then compiles everything with the native language tool, whether Maven, gradle, cargo or other, generates the optimized container for each language upload image on user registry and deploy to Kubernetes. All of these steps can be improved a lot, but the code generation mainly
    Marcel Lanz
    @marcellanz

    We could come up with our own equivalent of a CodeGeneratorRequest, if we find that something more customized meets our needs. One question I have though is how easy is it to parse a set of proto files into a set of FileDescriptorProto (https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/descriptor.proto#L62). Haven't really found an API that lets you read a set of proto files and spit out those FileDescriptorProto object, does anyone know where that exists?

    @rynahanks protoparse does. The google.golang.org/protobuf packages do not provide any of that functionality.
    example usage: https://gist.github.com/marcellanz/eae0c23837b709999748191ab7c3f287#file-protos-go-L7-L14

    Adriano Santos
    @sleipnir
    @pvlugter Would it be possible to send a release with Actions for Java support? I need this to implement in other JVM languages.
    2 replies
    Ryan Hanks
    @ryanhanks
    Thanks @marcellanz
    Adriano Santos
    @sleipnir
    2 replies
    Marcel Lanz
    @marcellanz
    The Cloudstate Python Support has now Stateless Function Support. Thanks @GratefulTony for the work being done. thanks @sleipnir and @dcirne for reviews.
    😀
    Guy Youansi
    @ralphlaude
    Good news 😊
    Adriano Santos
    @sleipnir
    \0/
    Thanks @marcellanz for reviews too
    Viktor Klang (√)
    @viktorklang
    Very cool, great work @GratefulTony! :)
    Marcel Lanz
    @marcellanz
    @pvlugter have you planned to migrate the Go documentation to Antora? I'd be interested to then do changes to it with Antora.
    Peter Vlugter
    @pvlugter
    @marcellanz, yes, planning to convert all the docs. If you're not updating the Go docs currently, I can look to get them migrated over first.
    Marcel Lanz
    @marcellanz
    @pvlugter very gladly. I have not yet started. I saw that Kotlin docs where migrated and concluded the others will be too.
    Marcel Lanz
    @marcellanz
    @pvlugter thanks for converting the Go docs to Antora :)
    Adriano Santos
    @sleipnir
    \0/
    Marcel Lanz
    @marcellanz
    "Workers Durable Objects Beta: A New Approach to Stateful Serverless", https://blog.cloudflare.com/introducing-workers-durable-objects/