should frontend call different apis

[Raif Harik]

Hi, I have a question about where the responsibility lies.

Let's say I have an api that serves a frontend application.  That application needs some info that is outside of the bounded context, but within the eco system (not some third party api).  The frontend could send a query to it's api and have that endpoint then query the target api then return the value, or the frontend could just call the target api and leave the serving api out of it. 

One might run into cors issues with the outside call, but that can be handled. 

Any thoughts would be appreciated.

R

[Greg Young]

both are viable options, where do your prefer your view composition in
the backend or in the fronted (there are trade offs to each)

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Bryan Watts]

> That application needs some info that is outside of the bounded context

Bounded context of what? Is a UI scoped to a bounded context? What about the idea of a composite application?

--

[Raif Harik]

Oh noooo, If I wanted to think about it I would have gone to jabbr!

Just kidding, nice to hear from you Bryan, and you, as always, make a good point.  The ui isn't owned by the bc, 

R

[Bryan Watts]

"Never answering the question you asked since 2003"

[Raif Harik]

awesome!

That actually works out for me, as I tend to ask dumb questions!

[Kijana Woodard]

The assumption you made in your question is actually revealing.

What if the it were a 3rd party API?

What if the API is Google Maps?

Should the frontend have to route a request to Google Maps through a certain "context API"?

If so, why?

Greg's answer is sound. It depends on where you want to do the composition.

If *the* API is meant for 3rd party consumption, I'd do it on the server.

Otherwise, I could go either way depending on "factors". *

* Scratching around for a twist on "it depends". ;-]

[Raif Harik]

Yes I thought about that too.  Gregs answer makes sense for third party apis.  for bc apis Brian's answer makes sense.  

What do you mean by meant for 3rd party consumption?

thanks,

r

[Greg Young]

Depends what you are joining it with out of your own information (if
joining a lot then often better in view model if possible)
Depends if you are searching based on info from it (obviously hard to
search someone else's if not exposed)
Depends what their api looks like (can you know when things change)
Depends what % of the total data on the other side you are interested
in (let's pull all of google maps into a view model!)

Lots and lots of it depends here

[Greg Young]

"Yes I thought about that too. Gregs answer makes sense for third party apis."

doesn't matter 3rd or not

[Raif Harik]

This too is good information. All those points need to be taken into consideration. Hopefully if it's internal than the call you are making is tailored to your needs. But not always possible or the case.

thx

r

[Kijana Woodard]

"What do you mean by meant for 3rd party consumption?"

If your API is going to be consumed outside of your organization.

[Kijana Woodard]

Yup. I chose Google Maps as opposed to QuickBooks as an API that one would conceivably target directly from a front-end client.

But it's "it depends" all the way down.