Add GraphQL API to update the mutated short links

[andyyaldoo]

From #237

[oatovar]

I can take on this issue, and update everyone this Friday regarding the progress made.

[oatovar]

Required Steps

1. Propose GraphQL API schema changes
2. Add urlupdater.go and urlupdater_test.go to the usecases url package.
3. Add approved changes to GraphQL API schema and resolvers.
4. Update wire.go for dependency injection.
5. Integrate the update shortlink api with the frontend.
6. Toogle to true within the feature toggle

[oatovar]

GraphQL Schema

type AuthMutation {
    createURL(url: URLInput!, isPublic: Boolean!): URL
    updateURL(alias: String!, url: URLInput!): URL
    deleteURL(alias: String!)
}

[magicoder10]

@oatovar Looks great to me!

For your information, we may consider combining all operations on urls to a single place. Maybe still keep the separate interfaces. Not sure what to do yet. The goal is to reduce unnecessary complexities.

[oatovar]

@byliuyang Definitely understandable, making this flexible enough for future additions takes time.

[oatovar]

@byliuyang Should the user have the ability to mutate the short alias as well as the long link?

[magicoder10]

@oatovar I think so.

[magicoder10]

@oatovar It's seems that Facebook officially used only one input type: https://graphql.org/graphql-js/mutations-and-input-types/

[oatovar]

@byliuyang Thank you for the referenced example! In the example, the application doesn't verify if the content and author is ommited since the arugments are optional. In Short's case, the original url is always required during creation, so having one input where it's both optional for both creation and mutation would be misleading when using the schema. We could have one single input type where all fields are optional and enforce requirements in the implemenation, but it might lead to confusion down the road.

So far these are the two solutions with their tradeoffs:

Solution	Pros	Cons
One Input	Reusability and simplicity	Schema might cause confusion as to what arguments are required for each use case
Two Inputs	Explicit attribute requirements	Future addition to one input type would require modification of two input types the update input and creation input.

After going over the tradeoffs, I think that one input might be the better option at this time. The chances of causing confusion will be very low if the error handling explicitly describe failure reasons as it is now. However, I am open to either option and the changes required to update the current work on this feature will be very little regardless of the option taken. What are your thoughts?

[magicoder10]

@oatovar It's a hard a decision. We can go with 1 input for now and look back in the future.