4 ms·

This feels like over-engineering a problem at it's finest. Taking 3 lines of ubiquitous code and abstracting in a new way, when it already does what you need ou

This feels like over-engineering a problem at it's finest. Taking 3 lines of ubiquitous code and abstracting in a new way, when it already does what you need out of the box. The base url and header details such as api token can all be set in the client in an OOP way already[1] > What happens if the URL changes? Cool urls don't change. Use configs. [1] https://docs.guzzlephp.org/en/stable/quickstart.html https://docs.guzzlephp.org/en/stable/quickstart.html

theli0nheart 5y ago
Exactly what I came here to say. You don't sprinkle URLs throughout your codebase, as the OP apparently assumes one would normally do. You create a single class (or something similar) which abstracts the API calls. If the endpoint changes, you change it in one place. I honestly don't see how this solution makes this easier. If anything, I feel like it makes things more complicated and harder to understand.
- dhbanes 5y ago
  The endpoint URL should probably be stored in the environmental variable file.
  - theli0nheart 5y ago
    > The endpoint URL should probably be stored in the environmental variable file. As I mentioned, if the endpoint changes, you change it in one place. Storing your endpoint URLs in an env file is your personal preference, but that's all. Should has no place here. It doesn't matter whether it's an environmental variable file, a YAML configuration, a JSON file, or a secure remote KV-store. Barring low water marks, it doesn't really matter where you store your configuration—just make sure to store it in one place.
- that_guy_iain 5y ago
  To be fair it does seem to fit the way I think Laravel applications are built.
hospadar 5y ago
>> What happens if the URL changes? > Cool urls don't change. Use configs. I also kinda think that for many webapps, the risk of this is somewhat overstated. I've got tons of apps with a few hard-coded URL paths that point at other internal apps that I own. They don't break because I don't randomly remove URL paths from services. When I do need to change something, find-and-replace + an integration test keep me safe 99.99% of the time (and the blast radius from a failure like this is usually very small - obvious 404 error bubbles up immediately the first time someone hits something broken). That said, I agree that keeping constants like URL paths in configs is a fine idea. I also feel that common sense is required - a tiny webservice which makes a single request to one URL path probably is fine to just hard-code it (and in fact putting all constants into config might be overly obfuscating), but a big app which makes dozens or hundreds of calls obviously benefits from a config-oriented approach
- 9dev 5y ago
  > a tiny webservice which makes a single request to one URL path that's how they all start out, don't they?

theli0nheart 5y ago

Exactly what I came here to say. You don't sprinkle URLs throughout your codebase, as the OP apparently assumes one would normally do. You create a single class (or something similar) which abstracts the API calls. If the endpoint changes, you change it in one place. I honestly don't see how this solution makes this easier. If anything, I feel like it makes things more complicated and harder to understand.

dhbanes 5y ago
The endpoint URL should probably be stored in the environmental variable file.
- theli0nheart 5y ago
  > The endpoint URL should probably be stored in the environmental variable file. As I mentioned, if the endpoint changes, you change it in one place. Storing your endpoint URLs in an env file is your personal preference, but that's all. Should has no place here. It doesn't matter whether it's an environmental variable file, a YAML configuration, a JSON file, or a secure remote KV-store. Barring low water marks, it doesn't really matter where you store your configuration—just make sure to store it in one place.
that_guy_iain 5y ago
To be fair it does seem to fit the way I think Laravel applications are built.

hospadar 5y ago

>> What happens if the URL changes? > Cool urls don't change. Use configs. I also kinda think that for many webapps, the risk of this is somewhat overstated. I've got tons of apps with a few hard-coded URL paths that point at other internal apps that I own. They don't break because I don't randomly remove URL paths from services. When I do need to change something, find-and-replace + an integration test keep me safe 99.99% of the time (and the blast radius from a failure like this is usually very small - obvious 404 error bubbles up immediately the first time someone hits something broken). That said, I agree that keeping constants like URL paths in configs is a fine idea. I also feel that common sense is required - a tiny webservice which makes a single request to one URL path probably is fine to just hard-code it (and in fact putting all constants into config might be overly obfuscating), but a big app which makes dozens or hundreds of calls obviously benefits from a config-oriented approach

9dev 5y ago
> a tiny webservice which makes a single request to one URL path that's how they all start out, don't they?