Add support for DynamoDb.
Feature Description
Are you planning to add DynamoDb support, or it's already there ?
Describe the solution you'd like
https://github.com/guregu/dynamo
Describe alternatives you've considered
Additional context
Hi @manojown DynamoDb support is not there yet, Soon will be adding it.
If this has not already been picked, I would want to contribute.
Hi @manojown sure feel free to pick
Happy to help you if you need to know how to get started with new db provider
Thanks @lakhansamani , I'll go through the code and let you know in case of query.
You can duplicate this folder and rename new folder to dynamodb
server/db/providers/provider_template
Then you have to fill out all the methods that are part of it
Hey @lakhansamani , I was testing the code and it seems https://62cbc6738042b16aa7c22df2.mockapi.io/api/v1/webhook this api reached the max limit. :grimacing:
@manojown I have reset the api, Though you can always disable it by setting env to test https://github.com/authorizerdev/authorizer/blob/587828b59b5fdcdc3558174fa82eb1adbcc6971f/server/utils/webhook.go#L61
Hi @lakhansamani , Hope you doing well,
I have a question about pagination. In the current graphql schema, it appears to be limited to offset and limit, however in certain databases, it works with a cursor.
As I'm new to ghraphql, I just needed to ensure that:
changing the schema.graphqls file for Pagination and paginationInput after that running gql generator would work, or is there anything else I'm missing?
@manojown yes the procedure is correct. However it would be good to keep that abstraction of offset and limit at API level and run cursor till that limit on backend.
Also there is some error with latest go versions in gqlgen that I need to fix. So let me know if that doesnt work on your machine I can generate schema for you.
@lakhansamani thanks for quick reply. Yes, kindly assist me in generating the schema. Despite my efforts, I consistently receive exit status 1 (gql generate) even when using the --verbose mode. LastEvaluateKey ( cursor) is hash so type should be string.
Sure will share new schema with that change
@manojown I have added changes here: https://github.com/authorizerdev/authorizer/tree/feat/dyanmo-db-cursor
Though I am not very happy with this approach it would be good if we can abstract this for APIs and manage cursor at provider level. Reason for this is that lot of apis in frontend can break in dashboard.
@lakhansamani Yes, you are correct. I was thinking along the similar lines because we need to control the forward and backward cursor on the front end (not compatible) . What are your thoughts on the alternative method of looping through the data till the offset is not reached? Note- However this is not good for huge data because every time we need to loop till the offset or save the cursor for particular user and offset in cache. ( are you referring to save the cursor on server-side - sessionStore or Redis ) Even still, a search option should be included in the future as users may choose not to paginate through all of the pages in order to view or locate a certain item.
@manojown if we change api to support cursor, we will have to add support for same in all dbs That could result in to the breaking change.
I know this will be performance issue while dealing with large data but as initial version of dynamo db support lets go with looping & skipping till the offset on server side.
Also these paginations are admin only features used on dashboard so we can optimize them later.
But lets make sure we create issue for that once we release support for dynamodb.
Also yes while adding search and other features we can optimize this with cursor and that will open doors for other dbs as well.
WDYT?