Code generators

[jodosha]

In order to streamline the getting started process with Lotus, we want to provide an application generator. The implementation can take advantage of the code that Lotus CLI offers (see #23 ).

One pending question is about the default code structure that we want to support. After a lot of experiments with Lotus apps, I vote for microservices.

That architecture encourages developers to keep all the code under the application module and to not pollute Ruby global namespace. This makes easier to build/run multiple applications in the same repository / process and to eventually extract them, as the code base grows.

[AlfonsoUceda]

+1 I would like a code generator to build a microservices structure, I think is the best options for small and larges apps because a large apps before it was a small app and besides It will give us a quickly beginning with our new app.

And of course, implements with #23 binary it would be a nice icea ;)

[jdickey]

I can go along with this. For using the microservices architecture you've laid out, I'd just really like to see more detail on what (if anything) goes under frontend besides sessions. Maybe I'm just too heavily Rails-crippled, but I've learned to see session management as almost orthogonal to the app logic per se. (Integrating our eventual recommended app styles with tools like Devise or an equivalent to Rails' has_secure_password would be Good Things To (Eventually) Have.)

@jodosha, what are your thoughts on the "modulized" application structure you laid out as compared to microservices?

I'd finally really, really like to see the generator plus probably a tutorial or two on how to Gemify components within your Lotus app; I see that as one of the great largely missed opportunities in Rails, despite the efforts of Ryan McGeary and others several years ago. Ruby has a mechanism for sharing and reusing code that's so simple and effective other platforms' developers would almost literally kill for it; it would be huge if we could leverage that.

I'm probably a month away from having significant time to do more than cheerlead and/or throw popcorn until late July, but I am working at spooling myself up in Lotus as I get free cycles before then. Thanks again, Luca and team, for building something that could/should/will be great!

[ryanyogan]

The generator is in development, I was waiting for the PR containing the initially binary to be accepted. I am working on a tech talk for my companies lunch and learns and will be posting it almost immediately after as well. I'll keep the community posted, I am sure some tutorials will spring up prior to the generator being committed.

[jdickey]

Maybe we should think about generators, plural, especially if we (think we might eventually) want to support, say, microservices vs modulised architecture? How to structure the modules making up a generator so that (possibly large portions of) it can be repurposed to generate functionally equivalent but differently structured apps/components without adding too much bloated cruft to the output? That would be a neat trick that, e.g., Rails' "do things the curators' way or do it all yourself" generators explicitly don't even try to perform.

Just thinking out loud during a break in a very long "day". (It's midnight here and I'm on for another 3 hours.)

[jodosha]

@jdickey RE sessions, backend/frontend: In my day job at Litmus we have the frontend app, that's the one that our customers see everyday. They login with username and password, we handle sessions for them with a custom authentication system. Deployed on the same server we have a backend app, which is only for staff members. For security reasons we keep the sessions of this application separated from the one of the customer facing app. I hope you're still following me.. Well, that example in the README is trying to replicate this scenario.

@ryanyogan @jdickey RE generators: yes we probably need more than one. But let's start with the first that supports microservices, because it enforces the naming convention that I prefer the most with Lotus: Bookshelf::Controllers and Bookshelf::Views.

[ryanyogan]

To start I just want to get a base skeleton structure generator in place so more individuals can get to exploring the framework. This framework absolutely has some amazing input already and once the pavement has been laid, I have no doubt the community will start cranking on some amazing ideas. I must personally admit I still have much to learn about each individual module that makes up this framework. I can only speak from what I am doing with my company regarding microservices and how I have traditionally separated concerns. Can you give more insight into how you see this framework being broke apart into a modular architecture? I think that paradigm means something different to almost every Rails developer that has spent years picking apart the framework into their own idealistic modularized framework.

[ryanyogan]

An interesting concept nonetheless, the only thing I see as a down side is confusion on where do I start? Should I create a microservice or should I create (to be defined) a modular app. What are the pros and cons? For starting out, there will need to be quality documentation and having one way of creating Lotus applications will help the community jump on board with a lower learning curve... My 2 cents

[jodosha]

@ryanyogan That totally makes sense: generators help devs to get onboard quickly.
Again, I'd prefer to see the microservices first, because I'd like to see the naming convention described above, to become a standard for Lotus applications.

[jdickey]

@jodosha Understood; your comment clarifies back-end/front-end auth nicely. And I wasn't disputing the "let's start with microservices" approach; just saying "let's keep in the back of our minds as we're developing this generator that there are likely to be others, so not making componentisation/reuse unduly arduous would be a Very Good Thing."

@ryanyogan agreed about "[breaking] apart into a modular architecture". To me, that says "make turning components/features into built or unbuilt Gems a no-brainer". Your mileage will vary. And agreed; documentation is something we have to get "right" very quickly. I know of at least two other frameworks/major components for which inadequate/outdated doc was at least a major supporting cause of death.

And finally, @jodosha, I can relate to wanting the naming convention "to become a standard for Lotus applications." I'd humbly suggest recasting that as "to become a standard for Lotus microservice applications, and a default for other supported architecture(s)."

[ryanyogan]

+1 @jdickey

[namtih58]

@jdickey What do you think about a combined modularized/un-built gems structure, where modules exist as described in #19 which can then be extracted to built/un-built gems.

I don't really like this "modularized" application structure. It is not a huge departure from the rails way, If later I with to extract a built/un-built gem i am forced to go searching through the app to get all related code, where as in #19 I just have to extract a folder which has most if not everything, even routing for the module.

If a new dev joins the team its easy to point them to a module and not worry they will mess with functionality others are working on.

Such an approach would allow @jdickey approach where gems are extracted early, while also supporting a delayed approach to gem extraction.
Others could have it both ways where there are un-built gems and modules in the same app. That to me would be one of the best structure for the generators.

[jdickey]

@namtih58 If you're asking if I prefer the structure in #19 over the "modulized" mess in the README, absolutely. I agree with your criticisms of the older architecture; now we "just" have to write generators that support this modular (not "modulized", Rails Way-lite) convention.

[jodosha]

According to the chosen architecture, this feature should be able to set the right values in for the application's configuration. For instance, namespace, root, load_paths, templates (see #56 for this).

[ryanyogan]

I was pretty busy with work and wanted to know if any progress has been made on this, would anyone like some assistance this weekend on getting this out the door?

[viking]

Any news on this?

[roman-kiselenko]

@jodosha in lotus generators should work by some config file, like .yml where you can declare what folder structure want use something like this (just example):

# Microservices architecture
app:
  - backend:
      - application
      - controllers
      - public:
        - fonts
        - images
        - javascripts
  - frontend:
      - application
      - assets
      - controllers

# Modulized application
app:
    - controllers
    - templates
    - views
public:
    - fonts
    - images
    - javascripts

So i have config like this i think generators can generate any structure folder. What do you think? If this interesting case for lotus i can try realize some test version.

[jodosha]

@fishbullet What if the config file is missing? And where it should live?

[roman-kiselenko]

@jodosha if config file missing this should raise can't find config errors, i think gem should have some binary for generate bootstrap yml or user can create and pass as arguments path to yml file with right structure.

P.S. i think this support lotus case because i can create any structure of my project just declare in one file where folders should be placed.

[AlfonsoUceda]

I prefer use generator like this:

lotus new myApp --microservices

or

lotus new myApp --modulized

or something like this instead using yml

[roman-kiselenko]

@AlfonsoUceda So have only 2 ways for generators? (modulized, microservices) what if i don't want use one of it and how about:
Lotus has flexible conventions for the code structure. Developers can arrange the layout of their projects as they prefer.

[jodosha]

@fishbullet To recap your proposal:

% lotus generate bootstrap-configuration
% vim configuration.yml # add all the wanted directories..
% lotus new --configuration=configuration.yml

Is that correct? If yes, I find it cumbersome.

What we need to do for now is to offer a bare minimum skeleton, plus the microservices and the modulized options, like @AlfonsoUceda suggested.

For the future, I'd like to have something more flexible with a descriptive file (eg .lotusrc).

The last point about Lotus flexibility isn't about code generators, but about the properties of the framework. As now Lotus provides modularity (multiple micro apps running in the same process) and adaptability to the code structure that a developer decides.

Code generators are just a facility, you can create that directories manually and the framework already works.

[roman-kiselenko]

@jodosha okey.
it's just my suggestion.

i know many cli cumbersom in configuration, look into Make or tmuxinator configuration.

I have another idea, lotus generators can generate file one by one and after dev can organize how wanted.
something like this:

lotus generate controller:main:one_file
... generate controller ....

and result can be (this some example inside or without):

module Controllers
  module Main
    include OneFile::Controller

    action 'Index' do
      def call(params)
      end
    end
  end
end

# Action example
# class Show
#   include Lotus::Action

#    def call(params)
#        ...
#     puts params # => { :"rack.version"=>[1, 2], : ... }
#   end
# end

or model generator repository:

lotus generate model:article:repository
... generate model ....

result:

class Article
  include Lotus::Repository
  # ......
end

or model generator entity:

 lotus generate model:person:entity
 ... generate model ....

result:

class Person
  include Lotus::Entity
  self.attributes = :name, :age
end

What you think?

P.S. and can realize geerators for microservices scaffolding or modulized and put in to right folder

[jdickey]

Popping back in after too long a burial...

First, for the record, I loathe Yaml files for config. Especially when you've a standard or two to default to, it makes life nicer in quite a few ways (think testing, for one) to use a Ruby object. Have default config objects baked into the framework — which solves the 'missing config' problem; there's an overrideable default.

Yaml config may make sense in a hackish setting where the config or other data being defined is in a state of flux. For things like baked-in defaults, though, Ruby code is generally safer, faster, more easily testable and maintainable, and far easier to find an errant typo in. YMMV, but beware.

There are a few directory-builder-per-config classes out in the wild, and I've been meaning to write my own take on such for some time (pertinent to @fishbullet's earlier comment, inter alia).

All IMAO, of course… </hand_grenade>

[jodosha]

@jdickey 💯 Nothing to add, I totally agree.