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

HTTP client API - improve room users API #982

Merged
merged 13 commits into from
Sep 23, 2016

Conversation

michalwski
Copy link
Contributor

@michalwski michalwski commented Sep 13, 2016

This PR goes on top of #973

Proposed changes include:

  • user's management move to path /room/:id/users
  • id attribute to affiliation change messages initiated by the API

@michalwski michalwski changed the title Http client api improve room users api HTTP client API - improve room users API Sep 13, 2016
@michalwski michalwski force-pushed the http-client-api-improve-room-users-api branch from 4b114ec to 144e5fd Compare September 14, 2016 09:34
@michalwski michalwski force-pushed the http-client-api-improve-room-users-api branch from 144e5fd to 985eccf Compare September 14, 2016 10:15
@michalwski michalwski force-pushed the http-client-api-improve-room-users-api branch from 6f84653 to 939b5b1 Compare September 22, 2016 07:28
@michalwski michalwski force-pushed the http-client-api-improve-room-users-api branch from 939b5b1 to 892af90 Compare September 22, 2016 07:48
RoomID = given_new_room_with_users({alice, Alice}, [{bob, Bob}]),
{{<<"204">>, _}, _} = remove_user_from_a_room({alice, Alice}, RoomID, Alice),
Stanza = escalus:wait_for_stanza(Bob),
ct:pal("~p", [Stanza]),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to Elvis:

Remove the debug call to ct:pal/2 on line 151.

user_is_removed_from_a_room(Config) ->
escalus:fresh_story(Config, [{alice, 1}, {bob, 1}], fun(Alice, Bob) ->
RoomID = given_new_room_with_users({alice, Alice}, [{bob, Bob}]),
{{<<"204">>, _}, _} = remove_user_from_a_room({alice, Alice}, RoomID, Bob),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to Elvis:

The code in the following (LINE, COL) locations has the same structure: (141, 29), (149, 29).

@@ -116,13 +119,46 @@ messages_can_be_paginated(Config) ->
room_is_created(Config) ->
escalus:fresh_story(Config, [{alice, 1}], fun(Alice) ->
RoomID = given_new_room({alice, Alice}),
get_room_info({alice, Alice}, RoomID)
RoomInfo = get_room_info({alice, Alice}, RoomID),
assert_room_info(Alice, RoomInfo)
end).

user_is_invited_to_a_room(Config) ->
escalus:fresh_story(Config, [{alice, 1}, {bob, 1}], fun(Alice, Bob) ->
RoomID = given_new_room_with_users({alice, Alice}, [{bob, Bob}]),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to Elvis:

The code in the following (LINE, COL) locations has the same structure: (128, 16), (140, 16), (148, 16), (158, 16), (202, 16).

@@ -127,14 +127,14 @@ invite_to_room(Domain, RoomName, Sender, Recipient0) ->
ejabberd_router:route(S, R, iq(jid:to_binary(S), jid:to_binary(R),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to Elvis:

The code in the following (LINE, COL) locations has the same structure: (127, 20), (138, 20).

@michalwski
Copy link
Contributor Author

All the code duplicates where addressed by tuning the Elvis's DRY sensitivity.

@@ -210,10 +210,12 @@ is_subdomain(Child, Parent) ->

iq(S, R, T, C) when is_binary(S),
is_binary(R), is_binary(T), is_list(C) ->
UUID = uuid:uuid_to_string(uuid:get_v4(), binary_standard),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather call it Uuid, to keep casing consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually for UUID as it is not only var name but also shortcut for Universal Unique Identifier which in many places is referred as UUID. Also to me UUID is more readable then Uuid.

@@ -210,10 +210,12 @@ is_subdomain(Child, Parent) ->

iq(S, R, T, C) when is_binary(S),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more telling variable names would be useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I forgot to refactor this function.

Copy link
Collaborator

@bartekgorny bartekgorny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General remark: this approach gives more control over urls and allows producing nicer paths, but results in many modules and code duplication. Some of it could be avoided, because we have subcategories in commands, so:
/api/messages/[:with]
/api/rooms/[:id]
/api/rooms/[:id]/messages
could well be served by the same module.
Indeed, this:
/api/rooms/:id/users/[:user]
could not be auto-generated, because using subcategory you could only get:
/api/rooms/:id/[:user]/users
which doesn't make much sense. I'd suggest looking for a way to route multiple urls to the same module, so as not to add a module for every simple function.

@michalwski
Copy link
Contributor Author

  1. What do you consider code duplication here?
  2. It's very easy to route multiple urls to the same module, but then we'll end up in request handlers where we have to check the path, and method and whatnot before we decide what to do. When we separate the whole rooms' functionality to smaller modules implementing only one logically small subset of functionality, the implementation is more understandable but a bit longer.

@bartekgorny
Copy link
Collaborator

I mean modules like the mongoose_client_api_rooms_users, which mostly calls mongoose_client_api_rooms and adds little of its own logic. But it is a matter of taste. I'm a bit concerned about numer of modules, it is growing very fast, and there is already quite a lot of them.

@michalwski
Copy link
Contributor Author

This could be improved by using inaka/mixer. I'd rather have more modules where the functionality is clearly split and each module is responsible for one logical subset.
In the end we can organise all the REST modules into their own subdirectory or even separate mongooseim_rest app in apps dir.

@bartekgorny
Copy link
Collaborator

Sounds like a good idea. Anyway, as of today, that's all from me.

@michalwski
Copy link
Contributor Author

If so then let's merge the PR and move forward!

@bartekgorny bartekgorny merged commit 3c0fa40 into master Sep 23, 2016
@bartekgorny bartekgorny deleted the http-client-api-improve-room-users-api branch September 23, 2016 08:37
@michalwski michalwski mentioned this pull request Nov 8, 2016
@Nyco Nyco removed the ready label Nov 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants