Is routing API calls through my own RESTful API considered an acceptable strategy?

This question might be considered opinionated but I really can't seem to find a straight answer. So either I'm missing something or I'm asking the wrong questions.
So, I'm an undergrad student and new in the whole Spring app development and I'm currently creating an app with React acting as the frontend and building a RESTful API using Spring in order to support it with necessary operations for the backend. Among other services, the backend API I'm building is used as a middle-man forwarding calls to the Google Geocoding API and other 3rd party APIs. **My biggest question since I started this is, is this a valid strategy? ** (at least, something acceptable by industry professionals)

My Research

• The biggest pro that this method has is that it allows me to effectively hide my API keys from the client rendering any attacks impossible.
• At the same time, this whole process adds (I believe) unnecessary complexity and delay in the overall responses resulting in a possible hindered user experience.
• Something I'm not quite sure yet would be that I'll have to add async capabilities to the services exposed by my own API in order to facilitate multiple users. (This last part might be entirely wrong but I haven't been able to understand how multiple users are handled when querying the same endpoint concurrently.)
• I have used Apache JMeter to test the performance of the app on concurrent POST calls and it seems to be able to handle them on around 170ms. (I'll post screenshots of the results below.)

Code

I'll try to include code demonstrating the controller that's responsible for the calls to the Geocoding API.

@RestController
@RequestMapping("/api")
@Slf4j
@RequiredArgsConstructor
@Component
public class GeocodingController {
    private final OkHttpClient httpClient = new OkHttpClient();

    @PostMapping(value = "/reversegeocoding")
    public String getReverseGeocode(@RequestBody LatLng latlng) throws IOException, ExecutionException, InterruptedException {
        String encodedLatLng = latlng.toString();
        Request request  = new Request.Builder()
                .url("https://maps.googleapis.com/maps/api/geocode/json?" +
                        "language=en&result_type=street_address&latlng=" + encodedLatLng +
                        "&key=MY_API_KEY")
                .build();

        CallbackFuture future = new CallbackFuture();
        httpClient.newCall(request).enqueue(future);
        Response response = future.get();
        return response.body().string();

    }
}

The getReverseGeocode() method takes in as an argument the following object:

@Data
@AllArgsConstructor
@NoArgsConstructor
public class LatLng {

    double lat;
    double lng;

    public String toString() {
        return lat + "," + lng;
    }
}

So, the Request Body is mapped onto the above object once the request arrives.
Finally the CallbackFuture is just an adapter class based on this answer.

public class CallbackFuture extends CompletableFuture<Response> implements Callback {

    @Override
    public void onFailure(Call call, IOException e) {
        super.completeExceptionally(e);
    }

    @Override
    public void onResponse(Call call, Response response) {
        super.complete(response);
    }
}

JMeter Results

Yeah, this is done all the time. Not all external APIs are setup to allow for you to grant access to your users directly. You also may have requirements for logging and or access control. It does mean you need to dedicate your resources to the calls but unless you are expecting an excessive load its not worth optimizing for too far in advance. Sometimes you can offload the proxy responsibilities to something like nginix instead which can be more efficient than your application backend.

In my experience it is worthwhile to keep these proxies in their own separate package that is isolated from your other code where possible. Then if you need to scale them independently of your main app you can easily break them out.

Yes, this is an entirely valid strategy. There are many benefits to using this approach and whilst it can feel like it's adding unnecessary complexity, the benefits often out way the cost.

Firstly you're avoiding "leaky abstractions", the client shouldn't care how you implement a particular piece of functionality, they just care that it works! It also means that you should be able to change the implementation in the future without the client even knowing.

Secondly, you're decoupling your APIs from others. If the wrapped API changes, you can handle this yourself without the clients having to change their code (there will be times when this can't be done, but it offers a good defence to this).

Also, it gives you a convenient point to implement your own functionality around these APIs (rate limiting, access control and logging for example).

The @Async issue is not specific to wrapping third party APIs, it's an issue for all endpoints you have which have blocking IO.

It is common. Recently did this to a third party api adding Cross Origin headers so clients could perform cross origin requests. Also the original JSON was malformed in some cases so it was possible to cleanly handle that scenario.

The first is very easy with Spring boot and as you can just decorate the controller with @CrossOrigin(maxAge = 3600)