That architecture your colleague suggested is pretty common nowadays - it's called Single Page Application.
In terms of security the two methods are equivalent - in both cases the server is generating all data required for creating the page, and sending it to the client. The only difference is where and how this data gets formatted into to form displayed to the user.
For example, if you want to allow the user the search for products, in the classic approach the server will generate the entire HTML page with the list of products in it, and in the SPA approach the server will generate the same list of products, but instead of rendering HTML it'll serialize the list into XML or JSON or whatever other format and send the serialized list to the client.
Notice that in both cases:
- All the data required to display the products is transferred on the wire.
- Data not needed for displaying the products or for performing farther operations on them(like the product ID that even if you don't display it the client still need it in case the user clicks on the button for ordering the product) does not reach the client.
- The internal services are not publicly available - you can't query the DB directly even with SPA, only to invoke the method that generates the list of products(and any other method you decide to expose to the client - but you would have to expose similar services in the classic approach as well)
Security-wise, the only advantage of the classic approach over the SPA approach is that SPAs make it a bit easier to programmatically use your application - for example it's easier for me to create a script that runs every morning, logs in with my credentials, requests the list of products, and emails me if you've added a new product. But I could have done it with the classic approach as well - it would have been a little harder(because it's harder to extract the data from HTML page than from a serialization format) but it would have still been possible(I've actually done that a few times...)
