Amber: [CLI] [API] Provide project type option - Web vs Api

[ansarizafar]

Please provide an option to select project type (Web or Api) when using amber new command.

[eliasjpr]

@ansarizafar thank you for submitting this. We have thought about it and we think is a great idea to consider.

[ansarizafar]

A more modular design would be required. Each project requires a different set of features/shards.

I am not using sqllite, Mysql, redis, micrate, slang, testing, deployment but still these features/shards are added to my project.

Amber shard/Cli should only include minimum no. of shards. Cli should only generate a basic structure/files and have options to add other features like deployment, testing, sqllite etc. later on.
CLI can provide options/Ask questions like project type (Web, API), database (Mysql, Pg, Sqllite), Enable Testing, deployment required? etc then generate a project and add only relevant shards.

Fewer dependencies, Less boilerplate, less no of generated files means fast compile time, easier to understand and update.

[drujensen]

Hi @ansarizafar It sounds like your looking for a different solution that what Amber was designed for. Have you considered looking at Kemal for your solution? It takes a minimalistic approach where Amber is more designed as a full featured framework.

To be clear, we try to modularize and minimize dependencies as much as possible but some things are quite difficult to do and wouldn't be worth the effort. If you want to take a shot at it, we would be open to ideas on how to minimize it more than we already have.

[ansarizafar]

I have used Kemal and I think Amber is much better. Thanks for the amazing work. I wanted to say, It's better, If we can allow developers to add features gradually when required. If a developer only want to use Postgresql then why Mysql, Sqllite etc. shards are added to project.

[drujensen]

I disagree with Amber being much better than Kemal. They have two different goals. Did you mean its better for your use-case?

I agree with your last statement regarding eliminating shards that are unneeded. However, they are needed. The way we are including the CLI in the project requires the 3 db shards to be available in order to compile.

Before, we were downloading a pre-compiled package for the CLI but realized it was better to have this compiled with the project. It guarantees there is no version mismatch and eliminates any incompatibility issues.

The extra shards are ignored when the application is built if you didn't reference them. They are only needed for the CLI build. The compiler is smart enough to keep the binary small and only include what is needed. The end result is the same whether shards are downloaded or not. In the end, the trade off is well worth it. Yes, setup times are a little bit slower, but the advantages outweigh that cost.

I hope this clarifies why the db shards are included. If you have a better approach or think there is a better way to do this, let us know or better yet, provide a PR. ;-)

[elorest]

Because we have a pipelines. We can define api/web for different route groups. This can make api routes much faster because they don't load nearly as many handlers. Rails doesn't have a way to define different middleware for route groups so they create different projects for web api. Amber and Phoenix which we borrowed this concept from solve that issue in a more dynamic way.

I don't think shards are really an issue as they're just a little bit of code usually. If they contained binaries it would be an issue. Hopefully shards shallow clones though to avoid overhead on github which could make github upset with us.

[paulcsmith]

Just to throw in my 2 cents, I think an --api option would be great, but I think that by default having a lot of the common stuff is better because I think it's much easier to delete/remove stuff than it is to figure out how to add it. Adding options for removing stuff is fine, but a batteries included default seems nice to me.

It seems that's what the Amber team things as well, and I like it 👍

[marksiemers]

This has the 'help wanted' tag - is it defined what the fix would be here? I'm going to start a list:

• amber new [app_name] doesn't change
• amber new [app_name] --api guts whatever it can (unnecessary plugs, views, jasper-helpers, etc.)
• amber new [app_name] --web guts whatever it can (unnecessary plugs, JSON parsers/generators. etc.)

I'm thinking the --api option would be a higher priority, as the standard install should continue to work well for the 'web' version.

Any thoughts on this? After choosing what option(s) to implement, we can dig into the details of what exactly can be gutted for an API only Amber app.

[eliasjpr]

Let’s put this up in the priority list. This is a demand issue that is valuable

[marksiemers]

Any thoughts that amber new continues to do what it is doing, and that is the "web" version, and the optional --api will customize/gut things?

In favor?

[elorest]

In favor. Although it still seems that since we have a pipeline most of the
API versus web changes should happen there rather than on Project
initialization.

On Nov 1, 2017 4:23 PM, "Mark" [e-mail] wrote:

Any thoughts that amber new continues to do what it is doing, and that is
the "web" version, and the optional --api will customize/gut things?

In favor?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/amberframework/amber/issues/269#issuecomment-341261165,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHmpG98Wqv6Zlhydj4KmejxucXW4Zawks5syO9JgaJpZM4PcSb-
.

[marksiemers]

@elorest I think the effect will be on the subsequent use of the CLI - like scaffolding a resource for an API should be a bit different than for web.

[elorest]

@marksiemers hmmm. I was thinking that amber g scaffold would have a flag. Or even amber g api_scaffold I guess a project could store it's defaults though.

Here's my comment from above:

"Because we have a pipelines. We can define api/web for different route groups. This can make api routes much faster because they don't load nearly as many handlers. Rails doesn't have a way to define different middleware for route groups so they create different projects for web api. Amber and Phoenix which we borrowed this concept from solve that issue in a more dynamic way.I don't think shards are really an issue as they're just a little bit of code usually. If they contained binaries it would be an issue. Hopefully shards shallow clones though to avoid overhead on github which could make github upset with us."

--

WDYT?
@marksiemers @drujensen @eliasjpr

[eliasjpr]

This will be addressed after the next release I believe this should take priority afterwards

[marksiemers]

I am in favor of this idea:

1. Each scaffold command can take an --api option and generate code appropriately
2. When executing amber new using an --api option will store a setting that will default scaffolding to doing what the --api option does

Beyond scaffolding, this may have an effect on other generators (probably amber g controller)

[GuskiS]

Any progress on this one?

[faustinoaq]

@GuskiS Yeah, We are implementing a new "recipes" feature, so, we can provide a nice basic/api recipe, see: https://github.com/amberframework/recipes

@damianham WDYT? :sweat_smile:

[damianham]

Yes the recipes feature is ideal to solve this problem although we might want to have an api recipe with either granite or crecto ORM at the top level alongside default and also ORM specific recipes in api/granite, api/jennifer, api/crecto, api/mongo etc. The idea behind basic/granite basic/crecto was to create individual recipes for each ORM because including many ORMs in 1 recipe will become unwieldy.

@drujensen made a very good point that the recipes will become difficult to manage, as we release new versions of amber all the recipes will have to be updated and many recipes will make that more difficult. I suggested a method to overcome that by having recipe dependencies so that a recipe will first apply a dependent recipe before applying itself. With that technique we can break out the recipes into a base and diffs. We probably need to implement before/after hooks before to support this.

[faustinoaq]

@damianham Interesting Idea :+1:

[eliasjpr]

Fixed #792