What is prefix in your examples? I'm unsure because prefix usually implies "placed before", but it comes after the base URL in your examples. Suffix?
Would what you've outlined here be better described as a clear separation of concerns between the data gathering and the view logic? Furthermore, the components themselves are unconcerned about how it acquires its data so long as it gets them?
I do like the provider abstraction, though! However, the downside, from what I can tell, is that it is a light wrapper around Axios. I think the methods defined there are typically a part of what I describe below that's found in your core logic. I think you're trying to enforce an interface (which is good), but the downside of this, is more providers aren't added, so whatever pattern has been established means almost nothing at all. However, if there certainly are, this idea that you're capturing is known as the strategy pattern, that often comes up for anyone that's worked with an OAuth library to offer delegated auth.
I think what you've named, ApiCore or core is akin to the repository pattern -- providing an interface to perform CRUD operations against a resource.
An endpoint usually encompasses the entire URL. If you're up for a suggestion, mine would be resource in the canonical API and RESTful nomenclature sense. The resource that you're using as an example appears to be tasks resources.
Fair enough. If I added or created a new provider, rather than swapping/modifying existing code and possibly introducing a regression -- I'm typically for keeping legacy things around, doing a partial release to end users for something new, address any bugs, then switch over and remove the old. I like your emphasis on clean architecture which alludes me to the ideas surrounding "Clean Code" by "Uncle Bob" who is often attributed for the SOLID acronym. You may enjoy this repository: github.com/ryanmcdermott/clean-cod...
I like resource better, thanks. Especially since this abstraction directly address the resource in question in addition to any custom endpoints related to the resource. Good catch.
Thanks for the article! Looks like a really good read. 😄
Hi Michael -- interesting post.
What is
prefix
in your examples? I'm unsure becauseprefix
usually implies "placed before", but it comes after the base URL in your examples. Suffix?Would what you've outlined here be better described as a clear separation of concerns between the data gathering and the view logic? Furthermore, the components themselves are unconcerned about how it acquires its data so long as it gets them?
I do like the provider abstraction, though! However, the downside, from what I can tell, is that it is a light wrapper around Axios. I think the methods defined there are typically a part of what I describe below that's found in your core logic. I think you're trying to enforce an interface (which is good), but the downside of this, is more providers aren't added, so whatever pattern has been established means almost nothing at all. However, if there certainly are, this idea that you're capturing is known as the strategy pattern, that often comes up for anyone that's worked with an OAuth library to offer delegated auth.
I think what you've named,
ApiCore
or core is akin to the repository pattern -- providing an interface to perform CRUD operations against a resource.You're right,
prefix
would be better changed toendpoint
to make it more descriptive.This can be considered a light wrapper to axios but can really be changed to any provider you want pretty easily.
Thanks! I appreciate your experience and feedback!
An endpoint usually encompasses the entire URL. If you're up for a suggestion, mine would be
resource
in the canonical API and RESTful nomenclature sense. The resource that you're using as an example appears to be tasks resources.Fair enough. If I added or created a new provider, rather than swapping/modifying existing code and possibly introducing a regression -- I'm typically for keeping legacy things around, doing a partial release to end users for something new, address any bugs, then switch over and remove the old. I like your emphasis on clean architecture which alludes me to the ideas surrounding "Clean Code" by "Uncle Bob" who is often attributed for the SOLID acronym. You may enjoy this repository: github.com/ryanmcdermott/clean-cod...
I like resource better, thanks. Especially since this abstraction directly address the resource in question in addition to any custom endpoints related to the resource. Good catch.
Thanks for the article! Looks like a really good read. 😄
Happy coding, Michael! And thanks for sharing. These sorts of pieces keep me in the loop in JS land that I haven't worked in for about two years :)
Thanx for sharing the link David