Amplify-js: Amplify project progress/milestones
Is your feature request related to a problem? Please describe.
Over the past couple of weeks I have been working on a React Native app using AWS Amplify, and specifically using the DataStore. I am really liking it so far, keep up the good work!. Nevertheless I've run into some issues with the DataStore for which I opened issues on here and on @aws-amplify/cli.
I am wondering where I can best check for changes/updates/fixes? Currently I refresh the commits pages of these projects multiple times a day, for example: https://github.com/aws-amplify/amplify-js/commits/master I saw that Amplify JS has a couple of milestones, but so far I rarely see any changes to those.
Describe the solution you'd like
I am really excited to use Amplify and the DataStore and I would like to see a place where I can check the progress of these projects. Something better then having to refresh commit streams, checking closed pull requests, and navigating to the DataStore CHANGELOG.md file.
Is there like a project board somewhere that can be made visible to the public?
mdoesburg
All 4 comments
@brene @sammartinez @undefobj
mdoesburg
on 17 Apr 2020
Also seems like the DataStore docs could use some updating. Took me awhile to find out how to observe changes on one item and how to use connection's on the DataStore. I am still confused about the last one actually. :/
mdoesburg
on 18 Apr 2020
I too am worried about the lack of communication and the quality of documentation and the project in general.
We are trying to build our platform using amplify and it has just been such an incredible pain to get working. The documentation is incredibly lacking in the worst places or sometimes so badly structured you miss out on important pieces, particularly because even though this is a "package solution", you cannot get it running without some knowledge of the actual AWS services involved. Everything is related -- you need to be consulting the graphql transform docs along with the data store docs and both so on and so on, and advice in one piece of the documentation(for example in the graphql section) might be directly incompatible with certain technologies(such as DataStore).
The amplify CLI is incredibly fragile to work with and you can easily end up with what seems like a totally broken state in the cloud there is no recovering from. I have probably had to recreate 3 or 4 different environments under new names in order to fix something I broke(probably while trying to fix something else).
If it isn't letting you break stuff like that, it's probably erroring out in totally mysterious ways because you made an innocuous mistake, like referring to a non-existent key in another model(say, a spelling error), forcing you dive into the compiled code inside node_modules to add error logging to figure out what is going on... and that's only if you get a stack trace to go on, because sometimes you do and sometimes you don't.
Moreover, the CLI doesn't work installed properly as a dependency into your project, or at least it didn't for me when I started using amplify. The only way I could get it to work was to use npm (not yarn) to install it globally, which is super spooky and makes no sense unless it is depending on some kind of global state somehow somewhere. There are spelling errors in the help output for the CLI, and there are lots of undocumented flags that you can only really find by stumbling on them somewhere on github.
It seems that this may be changing because I've seen random references to some other way of invoking amplify in the new docs, but of course none of this is documented properly anywhere.
There is also at least one subcommand that you can run that will literally delete your entire amplify folder.. Well, it actually backs it up, and you probably won't notice this if the command runs properly, but since the CLI is so incredibly confusing to use, you're going to be hitting ctrl-C a lot.. and in this concrete case, if you hit ctrl-C at the right/wrong time, the state the CLI leaves you in is a deleted amplify folder + a backup folder that it never told you about.
Then when you finally try to deploy your project, it doesn't build properly because the default CLI version that seems to be installed is old as hell and you need to click through the right wizard to override the CLI with the newest.. which then delays all your builds by a good deal because it fetches the new version every time.
I've had so many funky issues that I've had to dig through the internet to solve using some obscure comment in an issue that I can't even list them all. I started actually trying to write down my problems in a separate file but I forgot about it and was naturally focused on trying to get actual work done instead.
I've gotten into the habit of updating the amplify-cli as well as all the amplify dependencies regularly, but that isn't without its risks either. It seems that there is little regard for keeping track of a buildable combination of libraries. You might update the auth library only to get a nice uncaught JS exception as a toaster when trying to log in, cannot read property clientMetadata of undefined, which on its own is surprising considering that the project uses TS and errors like this should be "impossible" assuming that the chosen types accurately mirror reality.
Generally it would be considered good SE practices not to change too many variables at once, but since the only info you can find on this particular error is a closed issue where the solution was to update dependencies, you start updating all the other dependencies hoping that today the combination of latest works.
Every single time I have tried to do something new in the course of this project, it has started with things not working out as the guides suggest. Not a single category that I have added has worked out of the box as described.
There are currently over 600 issues in this project alone, and it doesn't seem like the development team can keep up. A lot of the issues have no replies and the discussion board is totally dead.
All in all, if I had a real choice, I would not use amplify if I could avoid it. There is a clear lack of direction, focus and proper holistic management across the various components of the project, and there is a clear lack of quality assurance. I do not think any of the developers are actually using this product for real, apart from with contrived test cases when implementing features. But this is a typical case of a walled garden where you just get so much out of the box as long as you're working with AWS that it's hard to replace.. so I guess I'll keep trudging through the mud under the assumption that surely someone has successfully deployed a working amplify application, and if they can, then we probably can too.
EDIT: I'd just like to mention that I have many years of experience and have through the course of my time programming used hundreds and hundreds of libraries and frameworks across a lot of different languages. I am definitely not afraid of or unaccustomed to the occasional deep dive into github or library code to fix minor issues or invoking some arcane arts to get stuff working, so please do not discount my issues as ones of a confused beginner(though that's how this has made me feel at times, honestly).
saevarb
on 20 Apr 2020
Hi @saevarb and @mdoesburg -- thanks for taking the time to provide us with feedback. Totally hear you and see why things like refreshing our commit history is less than ideal. I'm new to the team and will be working on ways our engineering teams can communicate to the open source community more effectively. I see tools like a community chat and a public roadmap being very beneficial for updates/announcements, but nothing to announce right now. To help in the nearterm, we have an official Twitter account, as well as our Developer Advocate Nader posts new Amplify features. In terms of milestones -- we should be updating these regularly and I can take a pass to see if anything is outdated.
I'll raise your feedback to the team about ways to show progress other than Changelogs. The team is also working on doc updates to Datastore.
In terms of CLI feedback, Ive sent this issue directly to the folks who work on that aspect.
Lastly, we recently launched the Discussion tab and are still evaluating if it's an effective way to support the community. We are working on methods to bring in more contributions and Amplify engineer to dive in.
If you have other concerns, please feel free to contact me directly as alleviating community frustration is my main focus. I'd also like to run new initiatives by passionate folks like yourself moving forward.
mauerbac
on 1 May 2020
Related issues
ldgarcia
路
3Comments
rayhaanq
路
3Comments
ddemoll
路
3Comments
josoroma
路
3Comments
leantide
路
3Comments
Most helpful comment
I too am worried about the lack of communication and the quality of documentation and the project in general.
We are trying to build our platform using amplify and it has just been such an incredible pain to get working. The documentation is incredibly lacking in the worst places or sometimes so badly structured you miss out on important pieces, particularly because even though this is a "package solution", you cannot get it running without some knowledge of the actual AWS services involved. Everything is related -- you need to be consulting the graphql transform docs along with the data store docs and both so on and so on, and advice in one piece of the documentation(for example in the graphql section) might be directly incompatible with certain technologies(such as DataStore).
The amplify CLI is incredibly fragile to work with and you can easily end up with what seems like a totally broken state in the cloud there is no recovering from. I have probably had to recreate 3 or 4 different environments under new names in order to fix something I broke(probably while trying to fix something else).
If it isn't letting you break stuff like that, it's probably erroring out in totally mysterious ways because you made an innocuous mistake, like referring to a non-existent key in another model(say, a spelling error), forcing you dive into the compiled code inside node_modules to add error logging to figure out what is going on... and that's only if you get a stack trace to go on, because sometimes you do and sometimes you don't.
Moreover, the CLI doesn't work installed properly as a dependency into your project, or at least it didn't for me when I started using amplify. The only way I could get it to work was to use
npm(notyarn) to install it globally, which is super spooky and makes no sense unless it is depending on some kind of global state somehow somewhere. There are spelling errors in the help output for the CLI, and there are lots of undocumented flags that you can only really find by stumbling on them somewhere on github.It seems that this may be changing because I've seen random references to some other way of invoking amplify in the new docs, but of course none of this is documented properly anywhere.
There is also at least one subcommand that you can run that will literally delete your entire amplify folder.. Well, it actually backs it up, and you probably won't notice this if the command runs properly, but since the CLI is so incredibly confusing to use, you're going to be hitting ctrl-C a lot.. and in this concrete case, if you hit ctrl-C at the right/wrong time, the state the CLI leaves you in is a deleted amplify folder + a backup folder that it never told you about.
Then when you finally try to deploy your project, it doesn't build properly because the default CLI version that seems to be installed is old as hell and you need to click through the right wizard to override the CLI with the newest.. which then delays all your builds by a good deal because it fetches the new version every time.
I've had so many funky issues that I've had to dig through the internet to solve using some obscure comment in an issue that I can't even list them all. I started actually trying to write down my problems in a separate file but I forgot about it and was naturally focused on trying to get actual work done instead.
I've gotten into the habit of updating the amplify-cli as well as all the amplify dependencies regularly, but that isn't without its risks either. It seems that there is little regard for keeping track of a buildable combination of libraries. You might update the auth library only to get a nice uncaught JS exception as a toaster when trying to log in,
cannot read property clientMetadata of undefined, which on its own is surprising considering that the project uses TS and errors like this should be "impossible" assuming that the chosen types accurately mirror reality.Generally it would be considered good SE practices not to change too many variables at once, but since the only info you can find on this particular error is a closed issue where the solution was to update dependencies, you start updating all the other dependencies hoping that today the combination of latest works.
Every single time I have tried to do something new in the course of this project, it has started with things not working out as the guides suggest. Not a single category that I have added has worked out of the box as described.
There are currently over 600 issues in this project alone, and it doesn't seem like the development team can keep up. A lot of the issues have no replies and the discussion board is totally dead.
All in all, if I had a real choice, I would not use amplify if I could avoid it. There is a clear lack of direction, focus and proper holistic management across the various components of the project, and there is a clear lack of quality assurance. I do not think any of the developers are actually using this product for real, apart from with contrived test cases when implementing features. But this is a typical case of a walled garden where you just get so much out of the box as long as you're working with AWS that it's hard to replace.. so I guess I'll keep trudging through the mud under the assumption that surely someone has successfully deployed a working amplify application, and if they can, then we probably can too.
EDIT: I'd just like to mention that I have many years of experience and have through the course of my time programming used hundreds and hundreds of libraries and frameworks across a lot of different languages. I am definitely not afraid of or unaccustomed to the occasional deep dive into github or library code to fix minor issues or invoking some arcane arts to get stuff working, so please do not discount my issues as ones of a confused beginner(though that's how this has made me feel at times, honestly).