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

Services refactoring proposal #427

Open
shmuga opened this issue Aug 2, 2019 · 2 comments
Open

Services refactoring proposal #427

shmuga opened this issue Aug 2, 2019 · 2 comments
Assignees

Comments

@shmuga
Copy link
Member

shmuga commented Aug 2, 2019

Following proposal describes refactoring of all services, their creation, uapi-request and some other minor things:

Idea 1: Static configs.

The idea to change all configs to be more static and related to requests. So this starts from making this config being static objects instead of dynamic function and all dynamic values would be appended/prepended during request construction.

Next step will be extracting most of these parameters for each request generator as static configs. So I see template, parser, error parser, validator, root, and url as part of some named config field.

After that settings could be directly passed to uapi-request without any pre-processings.

The goal of this stage is to couple all functions, request meta-data into one places and reuse it across all the code to eliminate such ambiguity in tests.

Idea 2: Tests refactoring.

Next step I see is to move tests closer to their sources, by putting them into same folder and unify the way we get fixtures for them. Having single config with all required meta-data for request can simplify tests preparations.

Resulting code will have some global testing functions that have an ability to loading fixtures and maybe some other useful stuff.

Idea 3: Async for all the goods

Since we support only node8 logical step would be changing promises to async/await functions and simplifying logic we have in services. This also involves revising tests we have for them.

I'll appreciate your thoughts on that alongside with any other ideas
/cc @dchertousov @cursedcoder

As soon as we get single vision I'll create separate tasks and a milestone for this refactoring.

@shmuga shmuga self-assigned this Aug 2, 2019
@cursedcoder
Copy link
Member

I would take a look at uapi-parser, this thing does some uncertain parsing/merging under the hood and particular api method works with strangely transformed response data.

Maybe we can somehow make it more understandable and improve overall data flow. Afterwards it's possible to create coding environment where you don't need to check many 1klocs files to write a single method to retrieve fare price or anything else. Right now new developers struggle with a high density of different unstructured classes/methods.

Making async/await or refactor tests is cool, but I can't see much of benefit from them.

@dchertousov
Copy link
Member

Agree with @cursedcoder .
We need better structure for parsing, validators, and methods.
They should either be derived from dome base classes or use same helper functions.
I'd stick with classes though.

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

3 participants