search

Travelport-Ukraine / uapi-json

Best Travelport Universal API wrapper ever :airplane: :mountain_railway: :hotel:
https://travelport-ukraine.github.io/uapi-json/
MIT License
74 stars 60 forks source link

Services refactoring proposal #427

Open shmuga opened 5 years ago

shmuga commented 5 years ago

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.

cursedcoder commented 5 years ago

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 commented 5 years ago

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.