aws-amplify / amplify-cli

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development.
Apache License 2.0
2.81k stars 821 forks source link

RFC: Other Installer options for the CLI #2561

Closed kaustavghosh06 closed 4 years ago

kaustavghosh06 commented 5 years ago

Currently, the CLI uses npm as a package manager and requires users of the CLI to install npm with node version > 8.2 for successful installation of the CLI. This RFC is to gauge community interest around the CLI being published to other package managers if there's a disinterest in installing the CLI via npm or yarn.

Some of the options which we're considering are the following:

Please comment on this thread if you've faced issues with npm when installing the CLI and if you think adding additional installers would smoothen out the CLI installation process for you or your team.

undefobj commented 5 years ago

iOS RFC: https://github.com/aws-amplify/aws-sdk-ios/issues/1972 Android RFC: https://github.com/aws-amplify/aws-sdk-android/issues/1248

undefobj commented 5 years ago

Some additional options we would like feedback on:

mtliendo commented 5 years ago

Is there a separate thread where users were having issues with npm? Perhaps it's the bubble I'm in, though I just figured that since Amplify was a web/mobile framework, that most users would be comfortable using npm.

I suspect the native crowd (swift, java) devs may be the driving factor?

Thanks again for all the hard work on the package, apologies that I'm a bit off topic.

chrisdag commented 5 years ago

Some of my largest AWS clients run "hard shell" private VPCs where internet access is blocked by default and 99% of subnets are private. All communication to the external world, when allowed passes through SSL decrypting firewalls for analysis.

We mirror software repositories internally for simple things like Perl CPAN and R CRAN but the new generation of package managers used by modern frameworks (like npm) have client-server communication requirements that make a static private internal mirror effectively impossible.

We've since deployed some Nexus Repository Managers to handle the new generation of package managers which works ok. NPM is hosted here.

So please consider this a +1 vote for a simple tarball install method that we could host internally on a private HTTP mirror.

This is a minor side digression into my constant rant that most of the AWS best practices, evangelist outreach materials/talks along with nearly all of the published AWS design and deploy patterns just inherently assume that unrestricted internet egress is always available and always allowed. AWS Parallelcuster ruined my day last week when their newest release started trying to download crap from github instead of pulling from their regional S3 buckets or custom ami directly.

ILAsoft commented 5 years ago

I appreciate clean and easy options that are standard in the industry and work the same way across multiple OSes, so while brew is great otherwise, I really like that NPM is the supported option and would prefer for it to stay (at least as one of the main supported options). Having said that, and ss mentioned above, tar would be another great generic one to have as a fallback for everyone.

P.S. Thank you for opening this feedback process to the public - love the transparency!!

jkeys-ecg-nmsu commented 5 years ago

@mtliendo well one thing that sucks about npm install is that it's not an idempotent operation. I should not have to run npm install, get a single package that fails to install for some reason, manually install that package, re-run npm install, etc. until I get a working node_modules. And then sometimes you'll run npm install, get zero errors, run it again, and get updated or removed packages.

That being said, @kaustavghosh06 your OP implies that installing Amplify CLI, SDK and the Amp component libraries can currently be installed with yarn. If so this is an undocumented feature, or maybe requires a more advanced understanding of yarn. (Does yarn synchronize with an npm mirror, meaning all npm packages can be installed by yarn by default?) Either way yarn support should be documented.

mtliendo commented 5 years ago

I get your perspective--and I apologize in advance for the assumptions I'm going to make, though I hear feedback like that when I'm teaching devs that are newer to JS, specifically the JS package managers.

A couple of things to note about npm:


Regarding yarn:

Hope that helps, or at least demystifies some things! Happy coding!

ghost commented 4 years ago

Just on a related note, on Mac there was an issue installing amplify-cli via npm if node was installed via brew. After installing node via nvm (which by the way I installed via brew), I no longer had issues installing amplify-cli via npm.

So brew -> nvm -> node -> npm -> amplify-cli. Haha!!

rrrix commented 4 years ago

Personally, I find the hard dependency on node.js and npm to be a "necessary evil". The AWS CDK is in a similar situation in that is only available via node & npm. I don't think anyone actually enjoys using npm.

My qualification: I lead a small but diverse global (remote) team of developers and DevOps staff working on 100% AWS native services, including container based and serverless applications, using a variety of platforms and languages - JavaScript, TypeScript, React, Python, and Java, running on AWS Lambda, Fargate/ECS, using the whole gamut of related AWS services - Amplify Console, AppSync, API Gateway, DynamoDB, Aurora PostgreSQL, DocumentDB, etc.

I think there's a few unique perspectives and important discussion points where the user experience is degraded by node & npm being a prerequisite / requirement for use of the Amplify CLI:

1) npm/node doesn't come pre-installed on any major operating system (Windows, MacOS, or any Linux distro). This makes using the Amplify CLI just a little bit harder than it needs to be for new users. This is somewhat mitigated by being able to use 3rd party package managers on Windows (Chocolatey) and MacOS (Homebrew) to install node - but it's not safe to assume every developer can even have those tools installed (they may be blocked by company security policy, for example).

2) NPM the Company and NPM the Service are seen as a liability to some. Having lots of npm dependencies in a project can turn into a security nightmare if even one nested dependency is abandoned and security vulnerabilities are discovered.

Just as an example, @aws-amplify/cli has 41 direct dependencies, but when the dependency tree is fully resolved turns out to be 5568 packages installed under node_modules (counting multiple versions of each package), or 2004 unique packages (when ignoring multiple versions of the same package).

2a) HN recently had some excellent discussion on the various issues and challenges regarding npmjs.com: Ask HN: Why All the Hate for NPM?

3) Large parts of the Amplify Toolchain can be used without ever writing a single line of JavaScript or touching any Web UI Framework (React / Vue) or Mobile (iOS / Android) application functionality. I think it's entirely reasonable to use the Amplify Toolchain to build an AppSync GraphQL API leveraging DynamoDB, Aurora and Lambda for external consumption. For example, there could be multiple teams working on a large platform, where you have one team dedicated to the API and Database, one team working on the Web Frontend, and one or more teams working on the Mobile Applications. Obviously there are interdependencies between the teams and they must work together to be successful, but there are clear non-overlapping areas of responsibility and ownership.

For example, If I want to build an API (only the API - the frontend / UI is another team) using an AppSync GraphQL API and API Gateway with both AppSync Apache VTL and Python based Lambda Functions in front of an existing database (DocumentDB or Aurora for example) - I don't need node / npm to do any of that, except for installing and using the Amplify CLI.

4) For new users who aren't developing in JavaScript/TypeScript and don't have experience nor interest in jumping into the JS/TS swimming pool, this can be a frustrating and confusing problem. As @mtliendo mentioned, during the installation some packages will frequently output error logs in big red text in the console, and for the uninitiated, that can be confusing and intimidating.

kaustavghosh06 commented 4 years ago

Thanks for all the feedback. As of last week, we've released various installation and scaffolding options (npx scripts for JS projects, Gradle plugin for Android projects and Cocopods with Xcode build phases for iOS projects) to ease out this process.

Please read more about it out here - https://aws.amazon.com/blogs/mobile/introducing-aws-amplify-for-ios-and-android/

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.