Some suggestions - Githubissues

Relating to naming functions: The controller name is starting with Fly to indicate that it's using the framework and the method the endpoint is indicated with (fly + http request type) for example flyget. You can ignore the fly in the method names. Just use (http request type) for the method name for example get. The fly in the method name is not needed as the class already has Fly in it which tells us it's a controller.

    public FlyUser{
        public get();
        public post();
    }

This will do the same functionality with more natural naming.

Relating to the number of methods inside a controller: There are two options here: You can make every controller related to an entity like user and in it like the following

        FlyUser{
            get();
            post();
            delete();
        }

So it is like you have a lightweight user service.

You make it so that every controller has only one function in this case you are making something like a serverless function but with the full capabilities of java services. So you end up with a jar for every serverless function.

I recommend the second option as it's new and currently the serverless functions don't give the full capabilities of your framework.

Finally relating to the jars: Every jar contains all classes on the project and one controller. I think this will be more flexible for only the classes used by this controller and the configurations are included in the jar. For example, if I have a controller of user and it's using user-related classes and I have another controller of book and it's using book-related classes. After exporting the jars the user jar doesn't need the book-related classes and also the book jar doesn't need the user-related classes.

arakoodev / FlySpring

Some suggestions #9