Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for @model and @searchable #211

Open
mihaiblaga89 opened this issue Feb 11, 2019 · 12 comments
Open

Support for @model and @searchable #211

mihaiblaga89 opened this issue Feb 11, 2019 · 12 comments

Comments

@mihaiblaga89
Copy link

mihaiblaga89 commented Feb 11, 2019

Are there any plans to support those annotations? At the moment, if you add @model to a type it will provision a DynamoDB table for you automatically. Same goes for @searchable but for an Elasticsearch instance. I know I can provision them manually in Resources but it would be nice to do it automatically if those annotations are present.

@sid88in
Copy link
Owner

sid88in commented Mar 3, 2019

Hey @mihaiblaga89 we don't have plans to support these annotations yet but open to accepting PRs on it. Also please add links to appsync docs for the same in this ticket.

@mim-Armand
Copy link

Those annotations (and a bunch more, like @Auth and @connection) are part of the Amplify Model Transform Library and not standard AppSync or GraphQL annotations.
I wish AWS would implement them as part of the AppSync tooling instead! I don't know why it was designed upside-down, but that's the way it is! :/
I think there can be a work-around to enable those but that would require an step before deploying to transform those to standard graphql mappings. Feels a bit hacky for a solution but that's because the way this feature was implemented in Amplify.. if I get a chance I'll try to see if it's feasible as I would really like to have those annotations as well.

@mim-Armand
Copy link

mim-Armand commented Mar 7, 2019

Actually Looks like @appwiz is working on this!

💯 👍

@mihaiblaga89
Copy link
Author

mihaiblaga89 commented Mar 7, 2019 via email

@mim-Armand
Copy link

mim-Armand commented Mar 7, 2019

How is it possible that @auth works but @model doesn't? @auth has to be annotated with @model as well, otherwise it throughs an error.
If it's working for you somehow could you give me an example of how you are using it?

Auth is and was working. Tested model but it isn't. Saw somewhere that they are baked in CF, so in theory it should not be a problem to add them as well

On Fri, Mar 8, 2019, 00:00 Armand @.***> wrote: Actually (Looks like)[https://github.com//issues/151 <#151>] @appwiz https://github.com/appwiz is working on this! 💯 👍 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#211 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AEkOuqGkx9LNCYWbp9XT3CuF_IIp5HgRks5vUYvmgaJpZM4a03Kd .

@mihaiblaga89
Copy link
Author

mihaiblaga89 commented Mar 7, 2019 via email

@mim-Armand
Copy link

You right! it does work now! that's awesome! it uses a query expression to return null if the user id is different in the context ( I believe that's the same lib that Amplify uses ).. Just what I needed

@bboure
Copy link
Collaborator

bboure commented Mar 18, 2019

@mihaiblaga89 @mim-Armand anyone knows how @auth is working?
I haven't tested yet. Has it been integrated directly into AppSync?
I cannot find anything in the doc. Only about aws_auth, here: https://docs.aws.amazon.com/appsync/latest/devguide/security.html
But the doc is very lacky!
Maybe it's just an alias or something?

Does your schema get deployed as-is (with the annotations)? Or does AppSync transform them somehow?

@mihaiblaga89
Copy link
Author

@bboure yes it does. I'm using it successfully in production for quite some time now.

After my queries and mutations I just add @aws_auth(cognito_groups: ["admins"]) for example and it just works. Keep in mind that you also have to use Cognito for this to work.

I'm also planning to release a package that will allow you to import gql types from other files and compile it into a single schema.graphql, to avoid that file from getting unmaintainable.

@bboure
Copy link
Collaborator

bboure commented Mar 18, 2019

@mihaiblaga89 Thanks @mihaiblaga89. I know about @aws_auth but I thought you guys were talking about @auth (like here) and seemed to say that it was working as well?

About GraphQL from different files, look at this recently closed PR #227 and this issue #230 :)
Sync with @trilliput if you wanna help.

@mihaiblaga89
Copy link
Author

mihaiblaga89 commented Mar 18, 2019

@bboure saw them, but it's easy to make mistakes, like forget a type or something. I've forked this package https://oss.prisma.io/content/graphql-import/overview and modified it to support the AppSync's custom scalars and annotations. I just need to publish it. Basically I have all the types separated into folders/files, import them in a main.graphql and the CI is running a grunt script that uses the plugin to merge all the schemas into one

@mim-Armand
Copy link

@bboure @auth works too, in fact that's the one I used and it's working, I don't think, however, if it's implemented into Appsync, I believe sls is using a library available in Amplify to transform those annotations.
In my case, it simply added a filter to Dynamo query that returns only items that belong to the authenticated user, I haven't yet tested more complicated auth mechanisms using a Lambda function.
The way you can use it is to simply put it in front of the item you want to protect in schema, the same way it's done in Amplify ( hence the reason I think that's what we are using here ): @auth(rules: [{allow: owner}]), there are additional options available, like changing the default owner field and more elaborate access controls, for those check Amplify documentations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants